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(54) Recording medium, recording apparatus, recording method, editing apparatus and editing 
method 

(57) It is an object of the present invention to sinn- 
plify work to edit sub data by: recording one or piurality 
of main data, nnanagement data for controlling the nnain 
data, one or plurality of sub data related to the main 
data and sub management data for controlling the sub 
data on a recording medium; and linking the sub data 
and the sub management data so that they can be ref- 
erenced from the management data. 
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Deecription 

[0001] The present invention relates to a recording medium for recording one or plurality of main data, management 
data for controlling the main data, one or plurality of sub data related to the main data and sub management data for 
5 controlling the sub data, a recording apparatus and a recording method for recording the data into the recording 
medium and an editing apparatus and an editing method for carrying out editing of the sub data recorded on the record- 
ing medium. 

[0002] In recent years, there have been developed audio or video apparatuses and information apparatuses for 
recording and playing back various kinds of data such as still-picture data, moving-picture data, musical data and audio 
10 data into and from a small-size recording medium with a solid-state recording devce such as a flash memory mounted 
thereon by using a dedicated drive unit or a general-purpose drive unit. 

[0003] With such a recording medium, recording and playback operations can be carried out for each of the appa- 
ratuses. In addition, it is expected that various kinds of data processing can be implemented in a system including an 
information apparatus such as a personal computer or another apparatus such as a CD player, an MD player and video 
75 visual equipment such as a video apparatus. 

[0004] There is a demand for processing to edit a file stored in a storage system using such a solid-state storage 
device. 

[0005] In addition, not only is an edit capability demanded, but there is also a demand for more efficient edit 
processing. In an efficient edit processing, for example, there is a demand for a minimum number of operations such as 
20 transfers, copying and rewriting of data required in file editing in a recording medium as well as a minimum edit process- 
ing time and minimum power consumption. 

[0006] In partbular, it is possible to conceive recording additional data into such a recording medium by associating 
the additional data with audio and video data. The additional data itself has a relatively large size. For this reason, there 
is also raised a demand for a high processing power of the processing apparatus to process additional data such as 
25 rewriting the entire additional data when it is desired to carry out editing work such as deletion of 1 piece of additional 
data 

[0007] In addition, even if such processing can be well carried out by for example an ordinary general-purpose per- 
sonal computer, the processing may be too large a load for a portable recording/playback apparatus in some cases. 
With such a condition taken into consideration, it is desired to provide a management system which allows editing work 
30 to be carried out as a small processing load with a high degree of efficiency. 

[0008] It is an object of the present invention addressing the problem described above to provide a management 
system for carrying out work to control and edit additional information as simple processing. 

[0009] According to a first aspect of the present invention, there is provided a recording medium for recording one 
or plurality of main data and one or plurality of sub data related to the main data, the recording medium comprising: a 
35 main data recording region for recording the one or plurality of main data; a sub data recording region for recording at 
least one of sub data file connprising the one or plurality of sub data and sub management data for controlling recording 
locations of the sub data; and a management data recording region for recording link information for controlling the main 
data recorded in the main data recording region and linking the main data to the sub data file containing the sub data 
related to the main data. 

40 [0010] According to a second aspect of the present invention, there is provided a method of recording data into a 
recording medium for recording one or plurality of main data, managemerrt data for controlling the main data and one 
or plurality of sub data related to the main data, the method comprising the steps of: recording the main data into the 
recording medium; recording the management data based on recording of the main data; recording a sub data file com- 
prising the one or plurality of sub data into the recording medium; and updating the management data so as to record 

45 link information for linking the main data to the sub data file as one of the management data. 

[001 1 ] According to a third aspect of the present invention, there is provided an editing method for carrying out edit- 
ing work by deletion of an invalid one of sub data recorded on a recording medium used for recording one or plurality 
of main data, management data for controlling the main data and a sub data file comprising at least one of the sub data 
related to the main data and sub management data for controlling the sub data wherein the sub data file is connected 

50 and linked to the management data, the editing method comprising: a data reading step of reading out the management 
data from the recording medium; a file reading step of reading out the sub data file from the recording medium in 
accordance with link information of the management data; a deletion step of deleting management data associated with 
sub data invalidated by sub management data in the sub data file and deleting the sub data determined to be invalid 
from the sub data file in case the sub data is determined to be Invalid on the basis of the sub management. data In the 

55 sub data file; and a file writing step of writing back the sub data file with unnecessary information deleted at the deletion 
step into the recording medium. 

[0012] According to a fourth aspect of the present invention, there is provided an editing method for carrying out 
editing work by deletion of sub data recorded on a recording medium used for recording one or plurality of main data, 



2 



ISDOCID: <EP 1055994A2J_> 



BP 1 055 994 A2 



management data for controlling the main data and a sub data file comprising at least one of the sub data related to the 
main data and sub management data for controlling the sub data wherein the sub data file is connected and linked to 
the management data, the editing method comprising: a data reading step of reading out the management data from 
the recording medium; a file reading step of reading out the sub data file from the recording medium in accordance with 
5 linl< information of the management data; a rewriting step of rewriting a specific one or plurality of sub management data 
associated with sub data specified to be deleted in the sub data file read out at the file reading step; and a file writing 
step of writing back the sub data file with the specific one or plurality of sub management data for the unnecessary sub 
data rewritten at the rewriting step into the recording medium. 

[0013] According to a fifth aspect of the present invention, there is provided a recording apparatus for recording one 

10 or plurality of main data, management data for controlling the main data and a sub data file comprising at least one of 
sub data related to the main data and sub management data for controlling the sub data into a recording medium, the 
recording apparatus comprising: recording means for recording the main data, the management data or the sub data 
file into the recording medium; first updating means for updating the management data stored on the recording medium 
on the basis of recording of the main data into the recording medium; sub data file generation means for generating sub 

75 management data for controlling at least one of sub data and creating a sub data file comprising at least the one of sub 
data and the sub management data; and second updating means for updating the management data so as to record 
link information associating the sub data file with the main data as one of the management data. 
[0014] According to a sixth aspect of the present invention, there is provided an editing apparatus for carrying out 
editing work by deletion of an invalid one of sub data recorded on a recording medium used for recording one or plurality 

20 of main data, management data for controlling the main data and a sub data file comprising at least one of the sub data 
related to the main data and sub management data for controlling the sub data wherein the sub data file is connected 
and linked to the management data, the editing apparatus comprising: reading means for reading out the information 
from the recording medium; writing means for writing the data into the recording medium; judgment means for forming 
a judgment as to whether or not there is an invalid one of sub data on the basis of the sub management data in the sub 

25 data file read out from the recording medium by the recording means; and control means for controlling work to edit the 
sub data file in case a result of the judgment formed by the judgment means indicates that there is an invalid one of sub 
data by execution of the steps of: deleting management data associated with sub data invalidated by the sub manage- 
ment data in the sub data file; deleting the sub data determined to be invalid from the sub data file; and controlling the 
write means to write the edited sub data file into the recording medium. 

30 [0015] According to a seventh aspect of the present invention, there is provided an editing apparatus for carrying 
out editing work by deletion of sub data recorded on a recording medium used for recording one or plurality of main 
data, management data for controlling the main data and a sub data file comprising at least one of the sub data related 
to the main data and sub management data for controlling the sub data wherein the sub data file is connected and 
linked to the management data, the editing apparatus comprising: access means for reading out and writing the data 

35 from and into the recording medium; and control means for controlling the access means to execute the steps of: rewrit- 
ing a specific one or plurality of sub management data associated with sub data specified to be deleted in the sub data 
file read out by the access means; and writing back the sub data file with the specific one or plurality of sub manage- 
ment data rewritten into the recording medium. 

40 Figs. 1 A through 1 D are diagrams showing, respectively, a top view, a front view, a side view and a bottom view of 
the external appearance! of a memory sheet provided by an embodiment of the present invention; 
Figs. 2A through 2E are diagrams showing, respectively, a front view, the top, the left side, the right side and the 
bottom of a drive apparatus provided by the embodiment; 

Fig. 3 is a block diagram showing the internal configuration of the drive apparatus; 
45 Fig. 4 is an explanatory diagram showing a typical system connection including the drive apparatus and the mem- 
ory sheet provided by the embodiment; 

Fig. 5 is an explanatory diagram showing a file-system processing hierarchy of the memory sheet provided by the 
embodiment; 

Figs. 6A through 6F are explanatory diagrams showing the data structure of the memory sheet provided by the 
50 embodiment in whteh 6A showing a data unit named a segment, 6B showing user blocks, 6C showing a page, 6D 

showing a redundancy portion of a page, 6E showing boot blocks and 6F showing a backup block; 

Fig. 7 is an explanatory diagram showing the directory structure of the memory sheet provided by the embodiment; 

Figs. 8A, 8B and 8C are explanatory diagrams showing, respectively, TRKLIST.IVISF, A3D(n).MSA and 

INFLIST.MSF consisting the management structure of the memory sheet provided by the embodiment; 
55 Figs. 9A, 9B and 9C are explanatory diagrams showing data files in which 9A showing the configuration of a data 

file #1 , 9B showing a boundary portion between parts and 9C showing the configuration of a data file #2, stored in 

the memory sheet provided by the embodiment; 

Fig, 1 0 is an explanatory diagram showing an operation to combine data files stored in the memory sheet provided 
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by the embodiment; 

Rgs. 1 1 A and 11 B are explanatory diagrams of a data file #1 and a data file #2 respectively each showing an oper- 
ation to divide a data tile stored in the memory sheet provided by the embodiment; 

Fig. 12A and 12B are explanatory diagrams in which 12A showing the data structure of a track-information man- 
5 agement file stored in the memory sheet provided by the embodinrient and 128 showing detailed configuration of 

TRKINF/PRTINF of the track-information management file; 

Fig. 13 is an explanatory diagram showing a low-order byte of the track-information management file A-nnn pro- 
vided by the embodiment; 

Fig. 14 is an explanatory diagram showing a high-order byte of the track-information management file A-nnn pro- 
10 vided by the embodiment; 

Fig. 15 is an explanatory diagram showing the data structure of NAMEl of the track-Information management file 
provided by the embodiment; 

Fig. 16 is an explanatory diagram showing the data structure of NAME2 of the track-information management file 
provided by the embodiment; 
75 Fig. 1 7 is an explanatory diagram showing the data structure of a data file provided by the embodiment; 

Fig. 18 Is an explanatory diagram used for describing recording modes of the memory sheet provided by the 
embodiment; 

Figs. 19A and 198 are explanatory diagrams in which 19A showing the data structure of an additional-information 
file provided by the embodiment and 1 98 showing the index pointer of the additional-information flie; 
20 Fig, 20 is an explanatory diagram showing the data structure of an additional-information unit provided by the 
embodiment; 

Fig. 21 is an explanatory diagram showing typbal additional information provided by the embodiment; 
Fig. 22 is an explanatory diagram showing a unit of additional information provided by the embodiment; 
Fig. 23 is an explanatory diagram showing a typical unit of additional information provided by the embodiment; 
25 Fig. 24 Is an explanatory diagram showing another typical unit of additional information provided by the embodi- 
ment; 

Fig. 25 is an explanatory diagram showing a further typical unit of additional information provided by the embodi- 
ment; 

Fig. 26 is an explanatory diagram showing an example of a deleted unit of additional information provided by the 
30 embodiment; 

Fig. 27 shows a flowchart representing processing carried out by the drive apparatus provided by the embodiment 
to record a file; 

Fig. 28 shows a flowchart representing processing carried out by the drive apparatus provided by the embodiment . 
to delete a file; 

35 Fig. 29 shows a flowchart representing file compression processing provided by the embodiment; and 

Figs. 30A and 308 are explanatory diagrams respectively showing an additional information file before and after 
the file compression processing provided by the embodiment. 

[0016] A preferred embodiment of the present invention is described as follows. It should be noted that a recording 
40 medium provided by the embodiment that is, a recording medium of the present invention, is exemplified by a memory 
sheet which is a memory having a planar external shape. 

[0017] A data processing apparatus of the present invention is exemplified by a drive apparatus capable of record- 
ing and playing back data into and from the memory sheet, 

[0018] A data file, a management file and an additional-information file provided by the present invention are exem- 
45 plified by a data file named A3Dnnnnn.MSA, a track-infomDation management file named TRKLIST.K/tSF and an addi- 
tional-infomnation file named INFLIST.MSF respectively which will be described later. 
[0019] The description is presented in the following order: 

1 . Memory Sheet 
50 2. Configuration of the Drive Apparatus 

3. Typical System Connection 

4. File System 

4-1 Processing Structure and Data Structure 
55 4-2 Directory Structure 

4-3 Management Structure 

4'4 Track-Information Management File (TRKLIST.MSF) 
4-5 Data Files (ASDnnnnn.MSA) 
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4-6 Additional-Information File (INFLISTMSF) 

5. File Recording Processing 

6. File Deletion Processing 

5 7. Processing to Compress the Additional-Information File 

1 . Memory Sheet 

[0020] First of all, the external shape of a memory sheet 1 used as a recording medium provided by the embodi- 
10 ment is explained by referring to Figs. 1 A to 1 D. 

[0021] The memory sheet 1 has a memory device of typically a predetermined storage capacity accommodated in 

a planar case like one shown in Rgs. 1 A to 1 D. In this embodiment, the memory device is a flash memory. 

[0022] Figs. 1 A to ID are diagrams showing a top view, a front view, a side view and a bottom view of the case 

which is formed by typically a plastic mold. As shown in the figure, as an example, the case has a depth W1 1 of 60 mm, 
15 a width W1 2 of 20 mm and a thickness W1 3 of 2.8 mm. 

[0023] On the front side of the bottom of the case, a terminal unit 2 comprising 10 electrodes is provided. Data is 

read out and written from and into the memory device through the terminal unit 2. 

[0024] The left upper corner of the case is a cut 3 oriented in the planar direction. The cut 3 prevents the memory 
sheet 1 from being mounted onto a mounting/dismounting mechanism in a wrong orientation of the case when the case 
20 is inserted into the mounting/dismounting mechanism. 

[0025] A label sticking surface 4 is provided over portions of the top and the bottom of the case. The user sticks a 
label for describing stored data on the label sticking surface 4. 

[0026] A slide switch 5 is provided on the bottom. The slide switch 5 prevents recorded data from being erased 
inadvertently. 

25 [0027] The storage capacity of the flash memory employed in the memory sheet 1 is prescribed to be 4MB, 8 MB, 
16 MB, 32 MB, 64 MB or 128 MB where notation MB is an abbreviation of megabytes. 

[0028] The so-called FAT (File Allocation Table) system is used as a file system for recording and playing back data. 
[0029] The write speed is 1 ,500 Kbyte/sec to 330 Kbyte/sec and the read speed is 2.45 Mbyte/sec. Data is written 
in units of 51 2 bytes and deleted in block units of 8 KB or 1 6 KB where notation KB is an abbreviation of kilobytes. 
30 [0030] The power-supply voltage Vcc is 2.7 V to 3.6 V and the serial clock signal SCLK has a maximum frequency 
of 20 MHz. 

2. Configuration of the Drive Apparatus 

35 [0031] The configuration of the drive apparatus 20 provided by this embodiment and capable of recording and play- 
ing back data into and from the memory sheet 1 is explained by referring to Figs. 2A to 2E and Fig. 3. 
[0032] It should be noted that the drive apparatus 20 is capable of handling a number of types of main data to be 
written and read out into and from the memory sheet 1 . Examples of the data are moving-picture data, still-ptoture data, 
voice data, audio data, musical data and control data. 

40 [0033] In the following description, the data is assumed to be mainly audio data or musical data. 

[0034] Figs. 2A to 2E are diagrams showing respectively a front view, the top, a left-side view, a right-side view and 
the bottom of a typical external appearance of the drive apparatus 20. 

[0035] The drive apparatus 20 is designed to have a small size and a light weight so that the user is capable of car- 
rying the apparatus 20 with ease. 
45 [0036] The memory sheet 1 Is mounted on a mounting/dismounting mechanism 22 provided on the top side of the 
drive apparatus 20 as shown in Fig. 2B. Various kinds of data such as musical data, audio data, rhoving-picture data, 
still-picture data, computer data and control data are recorded and played back by the drive apparatus 20 into and from 
the memory sheet 1 . 

[0037] A display unit 21 implemented typically by a liquid crystal panel is provided on the top of the drive apparatus 
50 20. The display unit 21 is used for displaying, among other things, a reproduced picture, information associated with a 
reproduced sound or a reproduced piece of music, a message serving as a guide of user operations and a menu screen 
for playback and edit operations. 

[0038] The drive apparatus 20 also has a variety of terminals for connecting the apparatus 20 to various kinds of 
equipment to be described later. 
55 [0039] For example, a headphone terminal 23 and a microphone input terminal 25 are provided on the top of the 

drive apparatus 20 as shown In Fig. 2B. 

[0040] A headphone is connected to the headphone terminal 23. The user is capable of hearing a reproduced 
sound whk:h is supplied by the drive apparatus 20 to the headphone as a playback audio signal. 
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[0041] A microphone is connected to the microphone input terminal 25. The drive apparatus 20 is capable of 
recording an input audio signal picked up l3y the microphone into typically the memory sheet 1 . 

[0042] Temninals such as a line output temninal 24, a line input terminal 26 and a digital input terminal 27 are pro- 
vided on the right side of the drive apparatus 20 as shown in Fig. 2C. 

5 [0043] A playback audio signal can be supplied to an external apparatus connected to the line output terminal 24 
by an audio cable. For example, by connecting an audio amplifier to the line output terminal 24, the user is capable of 
hearing a piece of musk: or a sound played back from the memory sheet 1 through a speaker system. As an alternative, 
by connecting a mini-disc recorder or a tape recorder to the line output terminal 26, it is possible to dub and record a 
piece of music or a sound played back from the memory sheet 1 into other media. 

10 [0044] In addition, an external apparatus such as a CD player can be connected to the line input terminal 26. In this 
case, an audio signal generated by the external apparatus can be supplied to the drive apparatus 20 to be recorded 
typically into the memory sheet 1 . 

[0045] Furthermore, the drive apparatus 20 is capable of inputting digital audio data transmitted by a digital source 
apparatus through an optical cable connected to the digital input terminal 27. An example of the digital source appara- 
15 tus is an external CD player. By connecting such an external CD player to the digital input terminal 27 by an optical 
cable, the so-called digital dubbing operation can be carried out. 

[0046] Terminals such as a USB (Universal Serial Bus) connector 28 and a power-supply terminal 29 are provided 
on the left side of the drive apparatus 20 as shown in Fig. 2C. 

[0047] The USB connector 28 Is connected to USB equipment such as a personal computer provided with typically 
20 a USB interface. In this case, the drive apparatus 20 is capable of carrying out various kinds of communication and data 
transmission with the USB equipnrtent 

[0048] The drive apparatus 20 provided by this embodiment employs a dry battery or a rechargeable battery 
embedded therein to serve as a power supply driving the operation of the drive apparatus 20. However, the power-sup- 
ply terminal 29 can be connected by a power-supply adapter to a commercial alternating-current power supply for pro- 
25 viding power to the operation of the drive apparatus 20. 

[0049] It should be noted that the types of these terminals, the number of terminals and their positions described 
above are typical to the bitter end. That is to say, as many tenninats of other types as required can be provided at posi- 
tions different from those described above. 

[0050] For example, a digital output terminal for an optical cable can be provided. Another example is the use of an 
30 SCSI (Small Computer System Interface) connector, a serial port, an RS232C connector, an IEEE 1394 (Institute of 
Electrical and Electrons Engineers 1394) connector or another connector. 

[0051] Since the structures of the terminals are already commonly known, their description is omitted. As an alter- 
native structure, however, a single terminal can serve as the headphone temiinal 23 and the line output temninal 24 or 
even also to serve as a digital output terminal. 
35 [0052] By the same token, the mbrophone input terminal 25, the line input terminal 26 and the digital input temiinal 
27 can be implemented by a common single terminal. 

[0053] Operators provided on the drive apparatus 20 to be operated by the user include an operation lever 31 , a 
halt key 32, a recording key 33, a menu key 34. a volume-up key 35, a volume-down key 36 and a hold key 37. 
[0054] The operation lever 31 is an operator that can be swung at least in the upward and downward directions. 
40 Typically, the operation lever 31 can also be pressed. By operating the operation lever 31 , it is possible to carry out an 
operation to play back musk^al data or the like, a REW and AMS (Auto Music Search] operation, a FF and AMS opera- 
tion or another operation. The REW and AMS operation is a fast-rewind and header-search operation whereas the FF 
and AMS operation is a fast-feed and header-search operation. 

[0055] The halt key 32 is a key requesting that an operation to play back or record musical data or the like be halted. 
45 [0056] The recording key 33 is a key making a request for an operation to record musical data or the like. 

[0057] A menu key 34 is a key operated to edittrtusicai data or the like or to set a mode. In an edit mode, an actual 
edit operation can be carried out by operating the operation lever 31 or carried out as an enter operation using this 
menu key 34. 

[0058] The volume-up key 35 and the volume-down key 36 are keys respectively to increase and reduce the volume 
50 of an output of an operation to play back musical data. 

[0059] The hold key 37 is a key for validating or invalidating the operating function of the other keys. When a key is 
pressed incorrectly while the drive apparatus 20 is being carried, for example, it is feared that a malfunction occurs. In 
this case, the hold key 37 Is operated to invalidate the OF)erating functions of the other keys. 

[0060] The keys described above Is of course no more than examples. In addition, the drive apparatus 20 can have 
55 other keys such as a cursor move key, numerk: keys and an operation dial or a Jog dial, 

[0061] A key for turning the power supply on and off is not shown. However, an operation carried put on the opera- 
tion lever 31 to make a request for a playback operation can also interpreted as an operation to turn on the power sup- 
ply. On the other hand, the power supply can be turned off automatically after a predetermined time has lapsed since 
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an operation carried out on the halt key 32. If such a scheme is implemented, a power-supply key is not required. Of 
course, a power-supply key can be provided. 

[0062] The number of provided operators, the types of the operators and the positions of the operators may con- 
ceivably vary in many ways. By providing the operators shown in Figs. 2A to 2E as an irreducible minimum, however, 
s the number of keys, the size of the drive apparatus 20 and the cost can be reduced and, in addition, the operatability 
can be improved. 

[0063] Fig. 3 is a block diagram showing the Internal configuration of the drive apparatus 20. 

[0064] A CPU 41 serves as a central control unit of the drive apparatus 20, controlling other components as 

described beiow. 

10 [0065] The CPU 41 includes an embedded ROM 41a for storing an operating program and a variety of constants 
and an embedded RAM 41b used as a work area. 

[0066] An operation unit 30 corresponds to the operators 31 to 37 described above. The CPU 41 caTies out control 
operations prescribed by the Operating program in accordance with information on an operation input received from the 

operation unit 30. 

15 [0067] A flash memory 48 is also provided. The CPU 41 is allowed to store system setting information and terminal 
key data in the flash memory 48. The system setting information is information on a variety of operations such as a 
music recording mode, a playback volume and a display mode. The terminal key data is used in processing to encrypt 
and decrypt or decode data. 

[0068] A real-time clock 44 serves as the so-called time unit for generating the present time of the day. The CPU 
20 41 is capable of verifying the present time of the day from data representing a date and a time from the real-time clock 
44. 

[0069] A USB interface 43 is a communicalion interface with an external apparatus connected to the USB connec- 
tor 28. The CPU 41 is thus capable of exchanging data with an external apparatus such as a personal computer through 
the USB interface 43. Examples of data exchanged with an external apparatus are control data, computer data, picture 
25 data and audio data. 

[0070] A regulator 46 and a DC/DC converter 47 serve as a power-supply unit. The CPU 41 turns on a power sup- 
ply by issuing a power-supply-on request to the regulator 46. Receiving the request, the regulator 46 starts receiving 
power from a battery. If an AC adapter is connected to the power-supply terminal 29, the regulator 29 rectifies and 
smoothens a supplied alternating-current voltage. 
30 [0071 ] A power-supply voltage generated by the regulator 46 is converted by the DC/DC converter 47 into a voltage 
of a required level which is supplied to each block as an operating power-supply voltage Vcc. 

[0072] The CPU 41 is capable of making an access to the memory sheet 1 mounted on the mounting/dismounting 
mechanism 22 through a memory interface 42. Thus, the CPU 41 allows operations to record, play back and edit data 
to be carried out. 

35 [0073] In addition, the CPU 41 is also capable of displaying a necessary picture on the display unit 21 by controlling 
a display driver 45. In addition to a picture, the CPU 41 may display information such as a menu of operations shown 
to the user on the display unit 108, a guide or contents of a file recorded in the memory sheet 1. The CPU 41 is also 
capable of displaying picture data read out from the memory sheet 1. Picture data stored in the memory sheet 1 typi- 
cally represents a moving or stili picture. 

40 [0074] As described above, the embodiment is provided with the digital input terminal 27, the microphone input ter- 
minal 25, the line input terminal 26, the headphone terminal 23 and the line output terminal 24 for inputting and output- 
ting audio signals. 

[0075] An audio-signal processing system for processing signals input and output through these terminals com- 
prise a SAM (Security Application Module) 50 serving as an encryption/decryption unit, a DSP (Digital Signal Proces- 
45 sor) 49, an A/D (analog to digital) & D/A (digital to analog) conversion unit 54 referred to hereafter simply as an ADDA 
conversion unit, a power amplifier 56, a microphone amplifier 53, an optical input module 51 and a digital input module 
52. 

[0076] The SAM 50 encrypts and decrypts (decodes) data exchanged between the CPU 41 and the DSP 49 and 
exchanges a tenninal key and an identifier serving as an encryption key with the CPU 41 . That is to say, the SAM 50 

50 encrypts and decrypts data by using a tenninal key. 

[0077] It should be noted that data encrypted and decrypted by the SAM 50 includes management information and 
additional information in addition to actual data stored in a data file such as musical data As will be described later, 
management information is data stored in a track-management information file and additional information is data stored 
in an additional-information file. 

55 [0078] The DSP 49 compresses and decompresses audio data in accordance with an instruction issued by the 
CPU 41. 

[0079] The digital input unit 52 carries out input interface processing of digital audio data input by the optical input 
module 51. 
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[0080] The ADDA conversion unit 54 cames out A/D conversion and D/A conversion of an audio signal. 
[0081] These blocks input and output an audio signal as follows. 

[0082] A signal supplied to the digital input terminal 27 from an external apparatus through an optical cable as dig> 
ital audio data is subjected to an opto-electrical conversion process in the optical input module 51 prior to reception 

5 processing carried out by the digital input unit 62 in accordance with a transmission format. Digital audio data extracted 
in the reception processing is compressed by the DSP 49 and supplied to the CPU 41 to be recorded into typically the 
memory sheet 1 . Of course, data output by the DSP 49 may be encrypted by the SAM 50 in some cases. 
[0083] An input audio signal supplied by a microphone connected to the microphone input terminal 25 is amplified 
by the microphone amplifier 53 before being subjected to an A/D conversion process in the ADDA conversion unit 54. 

10 The result of the A/D conversion process is supplied to the DSP 49 as digital audio data. After completing compression 
processing in the DSP 49 and, in some cases, an encryption process in the SAM 50, the data is supplied to the CPU 
41 to be recorded into typically the memory sheet 1 . 

[0084] On the other hand, in an operation to output audio data read out from the memory sheet 1 , for example, the 
CPU 41 requests the DSP 49 to carry out a decompression process on the audio data and, in some cases, requests 

75 the SAM 50 to carry out a decoding process on the data. Digital audio data completing these processes is converted 
by the ADDA conversion unit 54 into an analog audio signal before being supplied to a power amplifier 56. 
[0085] The power amplifier 56 carries out amplrfication processing for a signal to be output to a headphone and 
ampSif ication processing for a signal to be output as a line output, outputting the amplified signals to the headphone ter- 
minal 23 and the line output terminal 24. 

20 [0086] As will be described later, the drive apparatus 20 is capable of carrying out an encryption process in the 
SAM 50 on compressed audio data read out from the memory sheet 1 and audio data input from the digital input termi- 
nal 27, the microphone input terminal 25 or the line Input terminal 26 and compressed by the DSP 49, and capable of 
supplying the compressed data to an external apparatus such as a personal computer, by way of the USB interface 43 
and the USB terminal 28. 

25 [0087] In addition, audio data input from an external apparatus connected to the USB terminal 28 can be subjected 
to an encryption process in the SAM 50 before being supplied back to the external apparatus connected to the USB 
terminal 28. 

[0088] On the other hand, the drive apparatus 20 is capable of recording audio data received from an external 
apparatus via the USB interface 53 into the memory sheet 1 by means of the CPU 41 or, if necessary, decoding the 
30 data in the SAM 50 and decompressing it in the DSP 49 before outputting the data to the headphone terminal 23 or the 
line output temninal 24. In addition, the drive apparatus 20 is also capable of transmitting data to an external apparatus 
such as a personal computer through the USB interface 43. An example of data transmitted to such an external appa- 
ratus is received data completing a decryption process. 

[0089] It should be noted that the configuration of the drive apparatus 20 shown in Fig. 3 is typical to the bitter end. 
35 That is to say, the drive apparatus 20 is not limited to such a configuration. 

[0090] For example, the configuration may conceivably include an embedded speaker for outputting audio data. In 
this case, a signal output by the power amplifier 56 is supplied to the speaker whk:h then outputs a sound based on the 
signal. 

40 3. Typical System Connection 

[0091] Fig. 4 is an explanatory diagram showing a typical system connection with the drive apparatus 20 serving 
as a core component. 

[0092] The drive apparatus 20 can be used as a standalone component or used in a system in which the drive 
45 apparatus 20 is connected to another apparatus such as a personal computer 1 1 communicating with the apparatus 20. 
[0093] As described above, by mounting a memory sheet 1 on the drive apparatus i20, the drive apparatus 20 is 
capable of functioning as a standalone component capable of recording and playing back data into and from the mem- 
ory sheet 1 . 

[0094] With a memory sheet 1 for recording musical data mounted on the drive apparatus 20, for example, the user 
50 can enjoy reproduced music by connecting a headphone 1 2 as shown in Fig. 4. 

[0095] As described above, an external playback apparatus such as a CD player 1 0 can be connected to the line 
input terminal 26 or the digital input terminal 27 by a cable 13. With CD player 10 connected to the drive apparatus 20, 
the drive apparatus 20 is capable of receiving a playback audio signal from the CD player 1 0 and recording the signal 
into the memory sheet 1 . 

55 [0096] In addition, the drive apparatus 20 is also capable of recording a sound collected by a mk;rophone con- 
nected to the drive apparatus 20 into the memory sheet 1 . The drive apparatus is also capable of supplying data to a 
recording apparatus such as an MD recorder connected to the drive apparatus 20 to be recorded into a recording 
medium mounted on the recording apparatus. It should be noted that the mfcrophone and the recording apparatus 
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themselves are not shown in the figure. 

[0097] An information apparatus such as a personal computer 1 1 can be connected to the drive apparatus 20 by a 

USB (Universal Serial Bus) cable 14. In this case, the drive apparatus 20 is capable of recording data received from the 
personal computer 1 1 into the memory sheet 1 or transferring data played back from the memory sheet 1 to the per- 
5 sonal computer 11 in a copy or move operation. 

[0098] The destination of such a copy or move operation is typically an HDD 11a employed in the personal compu- 
ter 11 . 

[0099] It should be noted that the figure also shows a speaker 1 lb and a CD-ROM drive 1 1c provided on the per- 
sonal computer 1 1 . In this case, the drive apparatus 20 is capable of carrying out operations in conjunction with the per- 
10 sonal computer 1 1 . For example, the drive apparatus 20 is capable of recording audio data received from typically the 
CD-ROM drive 11c into the memory sheet 1 or decoding encrypted audio data received from the CD-ROM drive 11c 
and transferring back a result of decoding to the personal computer 1 1 . 

[0100] In addition, the drive apparatus 20 is capable of transferring audio data to the personal computer 1 1 to be 
output as a sound from the speaker 11b. 
15 [0101] Various kinds of equipment can be connected to the drive apparatus 20 as described above. As a result, 
while the drive apparatus 20 is being carried by the user, it is capable of performing recording and playback operations. 
In addition,.by connecting the drive apparatus 20 to various kinds of equipment placed at a home or a work place, the 
apparatus 20 is also capable of carrying out system operations. 

[0102] Furthermore, since the drive apparatus 20 provided by this embodiment has a display unit, the apparatus 20 
20 is capable of functioning as a standalone component to play back information such as text data and picture data 
recorded in the memory sheet 1 and display them on the display unit. Of course, information such as text data and pic- 
ture data played back from the memory sheet 1 can be displayed on a monitor screen of the personal computer 1 1 . 

4. File System 

25 

4-1 Processing Structure and Data Structure 

[0103] Next, a file system of this embodiment using the memory sheet 1 is explained. 

[0104] Fig. 5 is a diagram showing a file-system processing hierarchy of a computer system employing a memory 

30 sheet as a recording medium. 

[0105] As shown in the figure, in the file-system processing hierarchy, an application processing layer is the top 
layer sequentially followed by a file-management processing layer, a logical-address management layer, a physical- 
address management layer and flash -memory-access layer. In this hierarchical structure, the file-management 
processing layer is a FAT (RIe Allocation Table) file system. A physical address is assigned to each block in a flash 

35 memory. Thus, the relation between physical addresses and blocks is fixed. A logical address is an address treated log- 
ically at the file-management processing layer. 

[0106] Figs. 6A to 6F are diagrams showing a typical physical structure of data stored in the flash memory 
employed in the memory sheet 1 . 

[0107] As shown in Fig. 6A, a data unit named a segment in the flash memory employed In the memory sheet 1 is 
4o divided into a predetermined number of blocks each having a fixed length and, as shown in Fig. 6B. each block is 
divided into a predetemiined number of pages each having a fixed length. Data is deleted from the memory sheet 1 in 
block units but written and read out into and from the memory sheet 1 in page units. The blocks have a uniform size and 
the pages also have a uniform size as well. 1 block comprises page 0 to page m. 

[0108] 1 block has a typical size of 8 KB (kilobytes) or 16 KB while a typical size of a page is 512 B. In the case of 
45 a block size of 8 KB, the total storage capacity of the memory sheet 1 can be 4 MB equivalent to 512 blocks or 8 MB 
equivalent to 1 ,024 blocks. In the case of a block size of 1 6 KB, on the other hand, the total storage capacity of the mem- 
ory sheet 1 can be 1 6 MB equivalent to 1 ,024 blocks, 32 MB equivalent to 2,048 blocks or 64 MB equivalent to 4,096 
blocks. 

[0109] As shown in Fig. 6C, 1 page comprises a data portion with a size of 512 bytes and a redundancy portion with 
50 a size of 16 bytes. The structure of the redundancy portion is shown In Fig. 6D. In the first place, an overwrite portion 
with a size of 3 bytes is used as the header of the redundancy portion. The overwrite portion Is an area which can be 
rewritten In accordance with an operation to update data. The 3 bytes of the overwrite portion are respectively block sta- 
tus, page status and updating status arranged in a sequential order starting from the beginning. 
[0110] As a rule, data of the remaining 13 bytes in the redundancy portion Is fixed in dependence on the substance 
55 of the data portion. The 13 bytes are management flags of 1 byte, a logical address of 2 bytes, a format reserve area 
of 5 bytes, variance information ECC (Error Correction Code) of 2 bytes and data ECC of 3 bytes. The variance infor- 
mation ECC is redundant data for correction of errors in the management flags, the logical address and the format 
reserve area. On the other hand, the data ECC is redundant data for correction of errors in the 512-byte data portion 
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shown in Fig. 6C. 

[0111] The management flags are a system flag, a conversion table flag, a copy inhibit specification flag and an 
access pernn'rt flag. A system flag of 1 indicates a user block and a system flag of 0 indicates a boot biock. A conversion 
table flag of 1 indicates invalid and a conversion flag of 0 indicates a table block. A copy inhibit specification flag of 1 
5 indicates that a copy operation is permitted (OK) and a copy inhibit specification flag of 0 indicates that a copy operation 
is not allowed (NG). An access permit flag of 1 indicates a free access and an access permit flag of 0 indicates read 
protection. 

[0112] As shown in Fig. 6A, 2 blocks at the beginning of a segment, namely, blocks 0 and 1, are boot blocks 
whereas the rest is information blocks as user blocks. 
10 [0113] Used as a backup block, block 1 of the boot blocks shown in Rg. 6F has the same data written therein as 
block 0. Boot blocks are start blocks of valid blocks in the card of the memory sheet 1 . Boot blocks are blocks which are 
accessed initially when the memory sheet 1 is mounted on the drive apparatus 20. 

[0114] As shown in Fig. 6E, the first block of the boot blocks includes a header, a system entry and boot & attribute 
infonmation on page 0 at the beginning of the block. On page 1 , inhibited-use block data is stored whereas, on page 2, 

15 a CIS (Card Information Structure) and an IDI (Identify Drive Information) are stored. 

[0115] The header of the first boot block is used for recording a boot block ID and the number of valid entries in the 
boot block. The system entry is used for recording a start position of the Inhibited-use block data, the size of the data 
and the type of the data. The system entry is used for recording a start position of the CIS & IDI data, the size of the 
data and the type of the data. The boot & attribute information includes the type of the memory sheet 1, a block size, 

20 the number of blocks, a total block count, information indicating whether or not security is.supported and data related 
to manufacturing of the memory sheet 1 including a manufacturing date. The type of the memory sheet 1 indbates 
whether the memory sheet 1 is a read-only memory, a readable and writable memory or a hybrid memory, that is, a 
memory exhibiting characteristics of the 2 types. 

[0116] The above description explains the structure of data stored in the memory sheet 1 . 

25 [0117] By the way, an Insulation film of a flash memory may deteriorate due to operations to write data into the 
memory. In order to solve this problem, the number of write operations is limited. It is thus necessary to prevent 
accesses from being made repeatedly and persistently to the same storage area or the same block. Such accesses can 
be avoided in an operation to update data stored in a physical address by the file system as follows. A physbal address 
is seen by the file system of the memory sheet 1 as a logical address. Thus, an access to a logical address made by 

30 an application can be implemented by the file system as an access to a physical address determined arbitrarily by the 
file system. As a result, the file system is capable of updating data of a block subjected to the data updating operation 
and rewriting the updated data into another unused block instead of rewriting the data into the block subjected to the 
data updating operation. Therefore, the relation between a physical address and a logical address after the data updat> 
ing operation is different from the relation between a physical address and a logical address prior to the data updating 

35 operation. The operation to rewrite the updated data into another unused block instead of rewriting the data into the 
block subjected to the data updating operation is referred to as swap processing. By carrying out swap processing as 
described above, it is possible to prevent accesses from being made repeatedly and persistently to the same block. As 
a result the life of the flash memory employed as the memory sheet 1 can be prolonged. 

[0118] A logical address is assigned to data when the data is written into a block. Thus, even if the block after a data 
40 updating operation is different from the block prior to the data updating operation as described above, to the FAT sys- 
tem, the assignment of the logical address to the data stored in the block remains unchanged and the same logbal 
address can thus be used to correctly make an access to the data in the future. Since swap processing changes the 
relation between a logical address and a physical address, a logical-address/physical-address conversion table repre- 
senting a reiation between both addresses is required. By referring to this logicai-address/physicai-address conversion 
45 table, a physical address con-esponding to a logical address specified by an application can be identified by the FAT 
system which controls the table. As a result, an access to a block at the identified physical address can be made. 
[0119] The logical-address/physical -address conversion table is stored typically in the RAM 41b employed in the 
drive apparatus 20 but it can also be stored in the memory sheet 1 . 

[0120] Roughly speaking, logical addresses each having a length of 2 bytes are arranged in the logical- 
50 address/physical-address conversion table in an ascending order and a physteal address also having a length of 2 
bytes is assigned to each of the logical address. Since the maximum capacity of a flash memory is 128 MB (or 8,192 
blocks) and a physical address is assigned to each of the blocks, 8,192 addresses are sufficient. The logical- 
address/physical-address conversion table is controlled for each segment and its size increases in dependence on the 
capacity of the memory sheet 1 . Assuming that the storage capacity of the memory sheet 1 is 8 MB, or 2 segments, 2 
55 pages are allocated to a logical-address/physical-address conversion table for each of the 2 segments. 

[0121] A logical-address/physical-address conversion table can also be stored In the memory sheet 1 as mentioned 
above. In this case, a predetermined bit of the management flags in the redundancy portion of each page is set to indi- 
cate that a logical-address/physical-address conversion table for the page is stored in the memory sheet 1 . 
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[0122] The memory sheet 1 provided by this embodiment can be used by means of the FAT file system of a per- 
sona! computer in the same way as a disc-shaped recording medium. The memory sheet 1 Includes an IPL (Initial Pro- 
gram Loader) area, a FAT area and a root-directory area which are not shown in Fig. 6A. The iPL area is used for 
recording an address of a program to be initially loaded into a memory of the drive apparatus 20 and recording various 
5 l<tnds of information on the memory. The FAT area is used for recording matters related to blocks or clusters. To be more 
specific, the FAT area is used for prescribing values representing unused blocks, the number of a next block, bad blocks 
and the last block. The root-directory area is used for storing directory entries including file attributes, an update date 
and time, a start cluster and a file size. 

[0123] In this embodiment, file management information, or, to put it concretely, a track-information management 
10 file to be described later is prescribed for a musical file separately from a file management system prescribed in the for- 
mat of the memory sheet 1 described above. The track-information management file is recorded in a user block of the 
memory sheet 1 . With a recorded track-information management file, files can be recovered even if a FAT in the mem- 
ory sheet 1 is destroyed. 

[0124] A track- information management file is created by the CPU 41 . When the power supply is turned on for the 
15 first time, for example, the CPU 41 forms a judgment as to whether or not the memory sheet 1 is mounted. If the mem- 
ory sheet 1 is mounted, the memory sheet 1 is authenticated. If the memory sheet 1 1s verified to be a legitimate mem- 
ory sheet by the authentication, the CPU 41 reads out information from the boot block of the memory sheet 1 . Then, the 
CPU 41 reads out the logical-address/physical-address conversion table. 

[0125] Data read out by the CPU 41 is stored in the RAM 41b. Also in the case of a memory sheet 1 to be sold to 
20 the user for general applications, the FAT and the root directory are stored into the memory sheet 1 at a shipping time. 
[0126] The track-info nnation management file is created and updated for each recording operation. 
[0127] That is to say, when audio data Is recorded in accordance with typically an operation carried out by the user 
as a data file to be described later, the FAT and the track-information management file are updated after the recording 
operation. In an operation to update a file or, to put it concretely, each time a started operation to record audio data is 
25 completed, the FAT and the track-information management file stored in the RAM 41b are updated. Then, when the 
memory sheet 1 is dismounted or when the power supply is turned off, the final FAT and the final track-information man- 
agement file are transferred from the RAM 41 b to the memory sheet 1 . 

[0128] It should be noted that the FAT and the track-information management file stored in the memory sheet 1 can 
also be updated each time a started operation to record audio data is completed. Data of the track-information manage- 
so ment file is updated also after edit work is completed. 

[0129] In addition, in this embodiment, an additional-information file describing additional information is also cre- 
ated, updated and stored in the memory sheet 1 . The additional-information file is created and updated In the same way 
as the track-information management file. 

[0130] Additional information is supplied to the drive apparatus 20 by transmission from an external apparatus or 
35 by an input operation carried out by the user. The supplied additional information is stored by the CPU 41 in the memory 
sheet 1. The operation to record additional information will be described in detail later along with other operations. 

4-2 Directory Structure 

40 [0131] Next, the structure of files stored in the memory sheet 1 is explained. 
[0132] First of all, a typical directory structure is shown in Rg. 7. 

[0133] As described above, main data that can be handled by using the memory sheet 1 includes moving-picture 
data, still-picture data, vobe data, audio data, musical data and control data. In the directory structure, a root directory 
-has subordinate directories VOICE, DCIM, MOxxxxnn, AVCTL and HIFl. VOICE is a voice directory and DCIM is a still- 
45 picture directory. AVCTL is a control directory and HIFl is a musical directory. 

[0134] Since this embodiment has been exemplified by a case of recording and playing back music or audio data, 
only the HIFl musical directory is explained as follows. 

[0135] The HIFl musical directory includes a track-information management file TRKLIST.MSF, a backup fil6 TRK- 
LISTB.MSF of the track-information management file TRKLIST.MSF, an additional-Information file INFLIST.MSF and 

50 data files ASDnnnnn.MSA. 

[0136] The data file ASDnnnnn.MSA is a file for recording actual musical data, that is, audio data compressed in 
accordance with an ATRAC3 (Adaptive Transform Acoustic Coding) (trade mark) system. A data file ASDnnnnn.MSA is 
used for storing a piece of music. It should be noted that, in the following description, a data file is referred to as a track. 
[0137] The track-information management file TRKLIST.MSF is a management file in the musical directory and 

55 used for controlling pieces of music each stored typically in a data file as a TOO of a CD system or an MD system is 
used for. 

[0138] The track-infonnation management file TRKLIST.MSF includes NAME1 and NAME2. NAME1 is a block 
describing the name of the entire memory sheet 1 and musical names in terms of 1 -byte codes. That is to say, NAM El 
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describes data such as musical names in terms of ASCII/8859-1 character codes. On the other hand, NAME2 is a block 
describing the name of the entire memory sheet 1 and musical names in terms of 2-byte codes. That is to say, NAME2 
describes data such as musical names in terms of MS- J IS character codes, the Korean or Chinese language. 
[0139] The additional-information file INFLISTMSF is a file for controlling and storing additional information for the 
5 entire memory sheet 1 or data files each used for storing a piece of music, for example. To put it concretely, additional 
information stored in the additional-information file INFLIST.MSF includes the name of an artist, an ISRC code, a time 
stamp and stilt-picture data. 

4-3 Management Structure 

10 

[0140] Figs. 8A to 8C are diagrams showing relations among NAM E1 and NAM E2 of the track-information manage- 
ment file TRKLIST.MSF, the data file ASDnnnnn.MSA and the additionaMnformation file INFLIST.MSF which are all 
included in the musical directory. 

[0141] It should be noted that, in the description of this specification and the appended drawings, a number with a 
15 prefix Ox such as 0x001 0 for example, is a number expressed in the hexadecimal format. 

[0142] The track-information management file TRKLIST.MSF has a fixed total length of 64 Kbytes (= 16K x 4). A 
32-Kbyte portion of the track-information management file TRKLIST.MSF is used for storing parameters for controlling 
tracks or data files. The remaining 32-Kbyte portion is allocated to NAME1 and NAME2 described above. NAME1 and 
NAME2 which describe Information such as musical names can be implemented by treatment separate from the track- 
20 information management file TRKLIST.MSF. In the case of a system with a small RAM capacity, however, operations 
can be carried out more easily by handling the track-information management file TRKLIST.MSF and the musical-name 
file as a single management file instead of separate files. 

[0143] The data file ASDnnnn.MSA and the additional-information file INFLISTMSF are controlled by a track-infor- 
mation area TRKINF-nnnn and a part-information area PRTINF-nnnn in the track-information management file TRK- 
25 LIST.MSF. 

[0144] For one data file A3D (n), for example, a pointer and various kinds of other information are described in one 
track-information area TRKINF-(n) and one part-information area PRTINF-(n). In the example shown in Figs. BAto 8C, 
a track-information area TRKINF-(n) and a part-information area PRnNF-(n) are used for controlling a data file A3D (n) 
which comprises 4 parts PI to P4. 
30 [01 45] In this case, character information such as musical names for the data file A3D (n) are described In NAM El 
(n) and NAME2 (n). 

[0146] As will be described in detail later, the track-information area TRKINF-(n) describes a pointer pointing to an 
index pointer INF-(n) in the additional-information file INFLISTMSF. The index pointer INF-(n) in the additional-informa- 
tion file INFLIST.MSF further points to an additional-information unit INFU-(h) describing the actual substance of addi- 
35 tional information. The additional-information unit INFU-(n) is also stored in the additional-information file INFLIST.MSF. 
[0147] Units of additional information each associated with a data file are controlled in accordance with the scheme 
described above. 

[0148] It should be noted that the index pointer INF-(n) in the additional -information file INFLIST.MSF is referred to 
as a first pointer provided by the present invention. On the other hand, the pointer in the track-information area TRKINF- 

40 (n) pointing to the index pointer INF-(n) is referred to as a second pointer provided by the present invention. 

[01 49] Next, a relation between a data file and a piece of musb as a track is explained by referring to Figs. 9A to 90. 
[01 50] 1 track is 1 piece of music. The number of tracks that can be recorded in the memory sheet 1 is limited to a 
typical maximum of 400. 1 piece of music is stored in 1 data file. Data stored in a data file is audio data compressed in 
accordance with the ATRA03 method. A data file is recorded in the memory sheet 1 in units each called a cluster. A 

45 typical size of a cluster unit is 1 6 KB. Thus, a plurality of data files are never mixed in a cluster. 

[0151] A block is a minimum unit of deletion of data from the memory sheet 1 . In the case of the memory sheet 1 
used for recording musical data, the block has the same meaning as the duster and 1 cluster is defined to be equal to 
1 sector. 

[0152] 1 piece of music basbally consists of 1 part. However, a piece of music obtained as a result of editing work 
50 may comprise a plurality of parts. A link between parts in a piece of music is described by a part-Information area 
PRTINF-nnnn in the track-information management file TRKLIST.MSF. 

[0153] A part is a unit of data recorded in a continuous period of time beginning at the start of a recording operation 
and terminating at the end of the recording operation. Normally, 1 track consists of 1 part. There is a maximum limit on 
the size of a part. A relation between the number of parts and the number of tracks is defined by an equation 
55 P = 2,043-4 X T where notations P and T denote the number of parts and the number of tracks respectively and T has 
a value in the range 1 to 400. Assuming that 1 track comprises 2,039 parts, there are no enough parts that can be allo- 
cated to a second piece of music. Thus, a data file for the second piece of music can not be created. 
[0154] A minimum unit of a part is a sound unit abbreviated to an SU. An SU is a minimum data unit of audio data 
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compressed in accordance with the ATRAC3 nnethod. That is to say, an SU is a data unit with a size of several hundreds 
of b/tes. SUs are data units of a result of compression at a compressibility of about 1/1 0 of audio data of 1 ,024 samples 
(that is, 1 ,024 x 1 6 bits x 2 channels) obtained as a result of a sampling operation at a frequency of 44.1 kHz. If con- 
verted into a time, 1 SU is equivalent to about 23 msec. Normally, 1 part comprises several thousands of SUs. 
5 [0155] Figs. 9A to 9C are diagrams showing a file configuration of audio data recorded as 2 consecutive pieces of 
music from a recording medium such as a CD. 

[01 56] To be more specific. Fig. 9A is a diagram showing the configuration of data file #1 for the first piece of music 
comprising 5 clusters and Rg. 9C is a diagram showing the configuration of data file #2 for the second piece of music 
which comprises 6 clusters. 

10 [01 57] Since the end of the data file for the first piece of music and the beginning of the data file for the second piece 
of music can not be mixed in 1 cluster between the 2 files, data file #2 is created to start with a cluster following the last 
cluster of data file #1 . Thus, if data file #1 , that is, the first piece of music ends In a middle of a cluster, the rest of the 
cluster contains no data or no SU shown in Fig. 9B. 

[0158] The above statement also holds true of data file #2 for the second piece of music. 
75 [0159] In the above example, data files #1 and #2 each comprise 1 part. 

[0160] As work to edit data files stored in the memory sheet 1 . there are prescribed 4 types of processing, namely, 
divide, combine, erase and move. 

[0161] The divide processing is carried out to divide a piece of music into 2 portions. Thus, when divide processing 
is carried out, the number of musical pieces is increased by 1 . In divide processing, a file is divided Into 2 files from the 

20 file-system point of view, and the track-information management file TRKLIST.MSF is updated. The erase processing 
is carried out to delete a piece of music. The number of each musical piece following the deleted piece of music is dec- 
remented by 1 . The move processing Is carried out to change the order of musical pieces. The move processing can 
also be processing to move a piece of music from the memory sheet 1 to another medium such as a bard disc. The 
copy processing is carried out to duplicate an original piece of music while the move processing is processing to merely 

25 change the location of a piece of music. Thus, the move processing does not produce a duplicate. 

[0162] Fig. 10 is a diagram showing a result of processing to combine 2 pieces of music, namely, data files #1 and 
#2, shown in Figs. 9A to 9C. By carrying out the combine processing, data files #1 and #2 are combined into new data 
file #1 which now comprises 2 parts. 

[0163] Figs. 1 1 A and 1 1 B are diagrams showing a result of processing to divide a piece of music, that is, data file 
30 #1 shown in Fig. 9A in a middle of cluster 2. 

[0164] The divide processing of data file #1 results in new data files #1 and #2. New data file #1 comprises clusters 
0 and 1 and the front part of cluster 2, whereas new data file #2 comprises the rear part of cluster 2 and clusters 3 and 4. 
[0165] If data stored in data files itself is also updated in the various kinds of edit processing described above, it will 
take time and the processing load will increase, in order to solve these problems, only the track-information manage- 
rs ment file TRKLIST.MSF of a block, or cluster, including the edit point is updated. Thus, the concept of part is introduced. 

4-4 Track-Information Management RIe TRKLIST.MSF 

[0166] A detailed configuration of the track-information management file TRKLIST.MSF is explained by referring to 
40 Rgs. 12A, 1 28, 13, 14, 15 and 16 as follows. 

[0167] As shown in Figs. 8A to 8C, the track-information management file TRKLIST.MSF comprises 4 clusters or 4 
blocks each having a size of 1 6 KB to give a total size of 64 KB. However, Fig. 1 2A shows only the 32-KB first half com- 
prising the first and second clusters only. 

[0168] This first-half area with a size of 32 KB is used for controlling tracks or data files. 
45 [0169] It should be noted that, as described eariier by referring to Fig. 7, in addition to the track-information man- 
agement file TRKLIST.MSF, a copy of the track-information management file TRKLIST.MSF, namely, TRKLISTB.MSF, 
is also created. Since the latter has the same configuration as the former, however, the explanation of the latter is omit- 
ted from the following description of the track-information management file TRKLIST.MSF. 

[0170] In addition, the term slot used in the following description of each file is defined as a delimited unit of 8 or 1 6 
50 bytes starting from the beginning of a file. In the case of the track-information management file TRKLIST.MSF, the size 
of a slot is 16 bytes. In diagrams such as those shown in Figs. 12A, 12B, 17 and 19, a row in the horizontal direction 
comprises 8 or 16 bytes. Thus, such a row corresponds to a slot. 

[0171] The track-lnfonnation management file TRKLIST.MSF like the one shown in Fig. 12A has a 32-byte header 
at the beginning thereof. The header occupies slots (0x0000) and (0x001 0). 
55 [0172] The following pieces of data are sequentially arranged from the beginning of the header. 
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* BLK ID-TLO/TLI (4 bytes) 

[0173] This data is constants TLO = 0x544C2D30 and TL1 = 0x544C2D31 . 
s *T-TRK(2bytes) 

[0174] This data is the total number of musical pieces, having a value in the range 1 to 400. 

* MCode (2 bytes) 

10 

[0175] This data indicates manufacturer codes for identifying the manufacturer of the recording apparatus and the 
type of equipment. The codes are a control code for identifying the manufacturer of the recording apparatus used for 
recording data into the memory sheet 1 . The codes are given when the licenser grants a license. The equipment-type 
code is controlled by a company granting the license. 

75 

* REVISION (4 bytes) 

[0176] This data is the number of times the traclc-information management file TRKLIST.MSF has been revised so 
far. The number is incremented each time a recording operation is carried out. 

20 

*YMDhms(4bytes) 

[0177] This data is a date and a time on and at which the track-information management file TRKLIST.MSF was 
updated last. 

25 

* N1 (OP) (1 byte) 

[01 78] This data is a numerator-side sequence number of the memory sheet 1 . If only a piece is in use, the number 
is 0x01 for all. 

30 [0179] It should be noted that notation OP indicates that this data is optional. 

* N2 (OP) (1 byte) 

[0180] This data is a denominator-side sequence number of the memory sheet 1 . If only a piece is in use, a number 
35 is 0x01 for all. 

* MS ID (OP) (2 bytes) 

[0181] This data is the ID of the memory sheet 1 . If a plurality of sets are used, a uniform number (T. B. D.) is used 
40 as the MSID. It should be noted that the T. B. D. is an abbreviation of a phrase to be determined (defined) in the future*. 

* S-TRK (2 bytes) 

[0182] This data is a description of special tracks (401 to 408) T. B. D. Normally, this data has a value of 0x0000. 

45 

* PASS (OP) (2 bytes) 

[0183] This data is a password T. B. D. 
50 *APP (OP) (2bytes) 

[0184] This data is a description of a playback application T. B, D. Normally, this data has a value of 0x0000. 

* INF-S (OP) (2 bytes) 

55 

[0185] This data is a pointer pointing to additional information with the entire memory sheet 1 treated as an object. 
If there is no such additional information, this pointer is set at 00. 

[0186] It should be noted that the iNF-S is one of pointers referred to as the second pointers of the present inven- 
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tion. 

* S_YMDhms (OP) {4 bytes) 

5 [0187] This data is a date and a time on and at which the track-information management file TRKLIST.MSF was 
updated by an apparatus capable of recording a date and a time with a high degree of accuracy. 
[01 88] In addition to the header described above, as the last 1 6-byte of the first cluster of the trade-information man- 
agement file TRKLISTMSR BLK ID-TLO, MCode and REVISION which are identical with those of the header are 

described. 

10 [0189] In addition, as shown in the figure, BLK ID-TL1 , MCode and REVISION which are identical with those of the 
header are described in the first and last slots of the second cluster. 
[0190] They have the following functions. 

[0191] In a consumer audio apparatus, a memory sheet 1 may be pulled out or the power supply is turned off in the 
course of a recording operation. In such a case, it is necessary to recognize the generation of an abortion when the 

15 operation is resumed. As described above, REVISION is described at the beginning and the end of a block. Each time 
data of the block is updated, the value of REVISION is incremented by 1 . If an abortion occurs in the course of updating 
a block, the value of REVISION at the beginning of the block will be different from the value of REVISION at the end of 
the same block. Such a difference indicates that an abortion has occurred. Since the track-information management file 
TRKLIST.MSF has a backup file, however, it is easy to return the track-information management file TRKLIST.MSF to 

20 an immediately preceding revision. By providing a plurality of data items for REVISION in this way, an abortion can be 
recognized at a high probability. It should be noted that, when an abortion is recognized, a warning such as an error 
message is issued. 

[0192] In addition, the constants BLK ID-TLO and BLK ID-TL1 are inserted into the beginning of a 16-KB block. 
Thus, the constants can be used as standard references in the recovery of a destroyed FAT. That is to say, by looking 
25 at the constants described at the beginning of each block, the type of the file can be identified. Furthermore, the con- 
stants BLK ID-TLO and BLK ID-TL1 are described at both the start and the end of a block. Thus, reliability can also be 
checked. 

[0193] A data file for recording ATRAC3 data has a very large storage size in comparison with the track-information 
management file TRKLIST.MSF. For example, a data file may have a series of several thousands of blocks. With regard 
30 to a data file, a block number called BLOCK SERIAL is assigned as will be described later. It should be noted that, nor- 
mally, a plurality of data files exist in the memory sheet 1 . Thus, it is difficult to recover files in case the FAT is destroyed 
unless block numbers BLOCK SERIAL are assigned in addition to identification of contents by using content numbers 
CONNUMO to be described later. 

[0194] By the same token, a file problem caused by wrong logic may arise even though the FAT itself is not 
35 destroyed. However, a manufacturer code MCode is described at the beginning and the end of a block so as to allow 
the recorded manufacturer equipment type to be identified. 

[0195] In the track-information management file TRKLIST.MSF, the header is followed by a track-infomnation area 
TRKINF for describing information on tracks and a part-information area PRTINF for describing infomiation on a part in 
each of the tracks or pieces of music. 
40 [0196] To put it in detail, for example, the header is followed by a track-information area TRKINF-001 and a part- 
infonnation area PRTINF-001 for a track as a data file, a track-infonnation area TRKINF-002 and a part-information 
area PRTINF-002 for another track and so on. 

[0197] Details of the track-information area TRKINF and the part-Information area PRTINF are shown in Fig. 12B. 
Pieces of data described therein are described sequentially as follows. 

45 

* TO (1 byte) 

[0198] This data is a constant TO of 0x74. 
50 * LT (1 byte) 

[0199] This data indicates the existence or the non-existence of a playback limitation. An LT value of 0x80 indicates 
the existence of a playback limitation while an LT value of 0x00 indicates the non-existence of a playback limitation. 
Other values indicate that a playback operation is inhibited. 

55 

* INF-nnn (OP) (2 bytes) 

[0200] This data is a pointer pointing to additional information of the track. The pointer has a value in the range 000 
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to 409 specifying index pointers INF-001 to lNF-409 in the additional-infomnation file INFLIST.MSFto be described later. 
It should be noted, however, that the value 000 does not specify any index pointer. That is to say, a track with a pointer 
of 000 is not associated with addltfonal information. 

[0201 ] It is worth noting that IN F-nnn is also a pointer referred to as a second pointer provided by the present inven- 
5 tion. 

* FNM-nnn (4 bytes) 

[0202] This data is a file number in the range 0x0000 to OxFFFF assigned to a data file for storing ATRAC3 data. 
10 This data is obtained as a result of conversion of the ASCII characters nnnnn included in the data-file name 
A3Dnnnnn.MSA into the hexadecimal format Oxnnnnn. 

* CONTENTS KEY-nnn (8 bytes) 

75 [0203] This data is a special value created for each content and encrypted in a security block of the memory sheet 
1. 

* S-SAM (D) SERIAL-nnn (16 bytes) 

20 [0204] This data is a serial number peculiar to an apparatus used for recording data of the memory sheet 1 . 

* APP CTL (OP) (4 bytes) 

[0205] This data is an application parameter T. B. D. Normally, it has a value of 0x0000. 

25 

* CONNUM-nnn (4 bytes) 

[0206] This data is a content cumulative number which is created for each content. Content cumulative numbers 
are kept in the security block of the recording apparatus so that no cumulative number is duplicated in one memory 
30 sheet. 

* P-nnn (2 bytes) 

[0207] This data is the number of parts composing the piece of music (the data file). The number has a value in the 
35 range 1 to 2,039. 

* XT (OP) (2 bytes) 

[0208] This data is a playback time (SU) starting from a pointer represented by INX described below. It should be 
40 noted that a value of 0x0000 means no setting and a value of OxFFFF meansf the end of a piece of music. 

* INX-nnn (OP) (4 bytes) 

[0209] This data is a pointer pointing to a special portion in a piece of music. The pointer is expressed in terms of 
45 SUs relative to the beginning of the piece of music. Thus, the conventional music scan function allowing the user to hear 
a portion of only about 10 seconds in length from the beginning of a piece of music is improved and the special portion 

can be specified. 

* YMDhms-S (4 bytes) 

50 

[0210] This data is a date and a time on and at which operations to play back a track with a playback limitation can 
be started. A value of 0x00000000 Indicates that this data is not used. 

* YMDhms-E (4 bytes) 

55 

[0211 J This data is a date and a time by which operations to play back a track with a playback limitation are to be 
ended. A value of 0x00000000 indicates that this data is not used. 
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* MT (1 byte) 

[0212] This data is the number of times the operation to play back a track with a playback limitation can be carried 
out. A value of 0x00 indicates that this data is not used. 

5 

* CT (1 byte) 

[0213] This data is the number of times the operation to play back a track with a playback limitation have been car- 
ried out. A value of 0x00 indicates that this data is not used. 

10 

* CC (1 byte) 

[0214] This byte data is used for copy control. To be more specific, values of 00, 01 and 1 0 indicate copy prohibition, 
copying permitted only to produce a first generation and freedom of copying respectively. It should be noted that, in the 
75 case of "the copying permitted only to produce a first generation," an operation to duplicate a copy of the produced first 
generation is prohibited. 

* CN (1 byte) 

20 [021 5] This byte data is the number of copies. A value of 00 indicates copy prohibition and a value of OxFF indicates 
that an infinite number of copies up to the first generation can be produced. A value in the range 01 to OxFE Indicates 
the number of reproducible copies. Each time a copy is produced, a counter is incremented. 

[0216] The area of 64 bytes described above is the track- information area TRKINF-nnn and the last area of 16 
bytes shown in Fig. 12B is the part-information area PRTINF-nnn. 
25 [0217] The part-information area PRTINF-nnn is used for recording pieces of information on a part which are 
arranged in the following order. 

* PR (1 byte) 

30 [0218] This information is a constant PR of 0x50. 

* A-nnnn (2 bytes) 

[021 9] This information is attributes of the part. To be more specific, the attributes are a mode of 1 byte and an 
35 SCMS (Serial Copy Management System) information of 1 byte. Details will be described later. 

* PRTSIZE-nnnn (4 bytes) 

[0220] This information is a 2-byte cluster size, a 1 -byte start SU and a 1 -byte end SU of the part. 

40 

* PRTKEY-nnnn (8 bytes) 

[0221] This information is a key to be used as a pair in conjunction with a content key for creating a block key for 
encrypting musical data, its initial value is 0. Each time a part is generated in an edit operation,. this key is incremented 
45 byl. 

[0222] The 2-byte A-nnnn described above consists of a lower-order byte and a high-order byte for recording pieces 
of information shown in Rgs. 13 and 14. 

[0223] In the first place, the low-order byte of A-nnnn Is used for prescribing mode information showing a mode of 

the ATRAC3 system as shown In Fig. 13. 
50 [0224] Fig. 1 3 is a table showing the number of bytes in 1 SU, a recording time for a 64-MB memory sheet, a data 

transfer rate and a compressibility for each of 6 modes, namely, HQ, SP, CD, LP1, LP2 and mono. 

[0225] Information described in the hjgh-order byte is shown in Fig. 14. As shown in the figure, bit 0 is an emphasis 

bit indicating whether the emphasis function is turned on or off. Bit 1 is a playback-skip bit indicating a normal playback 

or a playback skip. Bit 2 is a data-segment bit representing infomiatlon indicating audio data or a data sound for FAX or 
55 the like is to be generated. Bits 3 and 4 are reserved bits. 

[0226] The combination of bits 5 and 6 is used to describe SCMS information as shown in the figure. 

[0227] Bit 7 is a write-protected bit indicating whether a write operation is permitted or prohibited. 

[0228] What is described above is an area for describing parameters for controlling a data file in the track-informa- 
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tion management file TRKLIST.MSF. 

[0229] As described above, the remaining 32-KB area of the track-information management file TBKLIST.MSF is 
used for describing NAME1 and NAME2. 

[0230] Fig. 15 is a diagram showing a detailed data structure of NAME1 which is a blocl< for describing information 
5 in terms of 1 -byte codes. NAME1 and NAME2 to be described later each comprise 8-byte units at an offset of a multiple 
of 8 bytes relative the beginning of the track-information management file TRKLIST.MSF. The 8-byte unit is referred to 
as a slot. The beginning of NAME1 is slot 0x8000 used for describing a header. The beginning slot 0x8000 is followed 
by pointers and names. The last slot of NAME1 is used for describing the same data as the header 

10 * BLK ID-NM1 (4 bytes) 

[0231] This data is a constant NM1 of 0x4E4D2D31 kJentifyIng the contents of the block. 

* MCode (2 bytes) 

15 

[0232] This data is a code for identifying the manufacturer and the type of equipment 

* PNMI-nnn and PNM1-S (OP) (4 bytes) 

2o [0233] These pieces of data are each pointer pointing to a 1*byte code NM1. To be more specific, PNM1-S is a 
pointer pointing to a name representing the memory sheet 1 . On the other hand, PNM1 -nnn, where nnn = 1 to 408, are 
each pointer pointing to the name of a piece of music. 

[0234] Each of the pointers comprises a start position of 2 bytes in the block, the type of the character code occu- 
pying 2 bits and the size of data occupying 1 4 bits. 
25 [0235] The start position Is an offset relative to the beginning of the NM1 area. Expressed in terms of bytes, the 
start position has a value in the range 0x000 to 0x3989. 

[0236] The type of the character code may have a value of 0 indicating the ASCII type, a value of 1 indicating 'ASCII 
+ tentative name' or a value of 2 Indicating the corrected 8859-1 type. 

[0237] The size of data which occupies 14 bits is the size of character data and an end byte of 0x00. This size has 
30 a value In the range 0x000 to 0x398C. 

*NM1-nnn (OP) 

[0238] This data is variable-length information expressed in terms of 1 -byte codes to represent the name of the 
35 memory sheet 1 or the name of a piece of music. The name is terminated by an end code of 0x00. 

[0239] Rg. 18 is a diagram showing a detailed data structure of NAME2, that is, an area for describing information 
in terms of 2-byte codes. 

[0240] The beginning of NAME2 is slot OxCOOO used for describing a header. The beginning slot OxCOOO isfolk>wed 
by pointers and names. The last slot of NAME2 is used for describing the same data as the header. 

40 

* BLK ID-NM2 (4 bytes) 

[0241] This data is a constant NM2 of 0x4E4D2D32 identifying the contents of the block. 
45 * MCode (2 bytes) 

[0242] This data is a code for identifying the manufacturer and the type of equipment. 

* PNM2-nnn and PNM2-S (OP) (4 bytes) 

50 

[0243] These pieces of data are each pointer pointing to a 2-byte code NM2. To be more specific, PNM2-S is a 
pointer pointing to a name representing the memory sheet 1 . On the other hand, PNM2-nnn, where nnn = 1 to 408, are 
each pointer pointing to the name of a piece of music. 

[0244] Each of the pointers comprises a start position of 2 bytes in the block, the type of the character code occu- 
55 pying 2 bits and the size of data occupying 14 bits. 

[0245] The start position is an offset relative to the beginning of the NM2 area. Expressed in terms of bytes, the 
start position has a value in the range 0x000 to 0x3987. 

[0246] The type of the character code may have a value of 0 indtoating the Japanese language (MS-JIS), a value 
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of 1 indicating the Korean language (KS C5601-1989) or a value of 2 indicating the Chinese language (GB2312-80). 
[0247] The size of data which occupies 14 bits Is the size of character data and 2 end bytes of 0x0000. This size 
has a value in the range 0x000 to 0x398C. 

5 * NM2-nnn (OP) 

[0248] This data is variable-length information expressed In terms of 2-byte codes to represent the name of the 
memory sheet 1 or the name of a piece of music. The name is terminated by an end code of 0x0000. 

10 4-5 Data Files ASDnnnnn.MSA 

[0249] Next, the structure of a data file ASDnnnnn.MSA for storing ATRAC3 data is described. 

[0250] Fig. 1 7 is a diagram showing a block of an array of data stored in a data file ASDnnnnn.MSA for an SU size 

of N bytes. 

15 [0251] This file comprises slots each having a size of 8 bytes. The slots shown in Fig. 1 7 start at 0x0000 and end 
at 0X3FF8. 

[0252] 4 slots at the beginning of the file are a header which includes pieces of data described below. The second 
slot is BLOCK SEED. A slot immediately preceding the last slot is also BLOCK SEED. The last slot is BLK ID-A3 and 
MCode. 

20 

* BLK ID-A3D (4 bytes) 

[0253] This data is a constant A3D of 0x41 324420 identifying the contents of the block. 
25 * MCode (2 bytes) 

[0254] This data is a code for identifying the manufacturer and the type of equipment. If the file is edited, it is nec- 
essary to update this code. 

30 * BLOCK SEED (8 bytes) 

[0255] This data is used for creating a block key required for encryption. A start value of the block seed is computed 
by the SAM (Security Application Module) 50 of the recording apparatus from a random number. The block seed of a 
next block is computed by incrementing the start value by 1 . As a technique to handle an error, the same block seed is 
35 recorded in the second slot and a slot preceding the last slot. In addition, it is not necessary to update the block seed 
even if the data file is edited. 

* CONNUM (4 bytes) 

40 [0256] This data is a content number obtained initially. This initial content number is initially the same as CONNUM 
of the track-information management file TRKLIST.MSF described eariier. It is not necessary to update the content 
number even if the data file is edited. 

* BLOCK SERIAL (4 bytes) 

45 

[0257] This data is the serial number of the block. The serial number of the first block is 0 and that of the following 
block is obtained by Incrementing the number of the current block by 1 . It is not necessary to update the serial number 
even if the data file is edited. 

50 * INITIALIZATION VECTOR (8 bytes) 

[0258] This data is an initial value required for encryption and decryption of ATRAC3 data. At the beginning of a 
content, the initial value is 0. In the next block, the Initial vector is equal to a last encrypted value of the last SU. It is not 
necessary to update the initial vector even if the data file is edited. 
55 [0259] Such a head is followed by sound units SU-nnnn arranged sequentially. An SU is data obtained as a result 
of compression of 1 ,024 samples. The amount of data varies from mode to mode. It is not necessary to update the 
mount of data even if the data file is edited. 

[0260] Fig. 1 8 is a table showing the amount of data, the number of SUs per block, the amount of margin data per 
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block, the transfer rate and the transfer time of a data file for each mode. 

[0261 ] In general, a memory sheet 1 having a size of 64 MB is used. Data for a CD mode of such a memory sheet 

1 Is explained. A memory sheet with a size of 64 MB has 3,968 blocks. In the CD mode, the size of 1 SU is 320 bytes. 
Thus, 1 block comprises 51 SUs which each correspond to (1 ,024/44,1 00) seconds. Therefore, the transfer time for the 
5 data file is: 

(1 ,024/44100) X 51 X (3,968-1 6) = 4,680 seconds = 78 minutes. 
[0262] The transfer rate is: 

10 

(44100/1024) X 320 X 8 = 1 10,250 bps. 

4-6 Additional-Information RIe INFLIST.MSF 

75 [0263] Next, the additional-information file INFLIST.MSF Is explained. 

[0264] Fig. 19A is a diagram showing a detailed data structure of the additional-information file INFLIST.MSF. 
[0265] Much like the track-information management file TRKLIST.MSF, the additional-information file INFLIST.MSF 

comprises slots each having a size of 1 6 bytes. 

[0266] Slot 0x0000, that is, a slot at the beginning of the addltlonal-infonnation file, is a header. The header is fol- 
20 lowed by pointers and pieces of data which are described after explanation of the header. 
[0267] The header comprises the following pieces of data. 

*BLK ID-INF(4bytes) 

25 [0268] This data is a constant INF of Ox494E464F identifying the contents of the block, 
*T-DAT(2bytes) 

[0269] This data is the total number of pieces of data in the range 0 to 409. 

30 

* MCode (2 bytes) 

[0270] This data is a code for identifying the manufacturer and the type of equipment 
35 * YMDhms (4 bytes) 

[0271] This data is a recording date and a recording time. 

* INF-nnn (4 bytes) 

40 

[0272] This data is an index pointer pointing to units of additional information to be described later. The units of 
additional information pointed to by the index pointer have a variable length expressed in terms of slots (or 2-byte units). 
[0273] Notations INF-001 to INF-409 denote the index pointers. 

[0274] it should be noted that the index pointers INF-001 to INF-409 are each referred to as a first pointer provided 
45 by the present invention. 

[0275] The index pointer INF-nnn with a length of 4 bytes has a configuration shown in Fig. 19B. To put It in detail, 
the 1 6 most significant bits are a pointer and the 16 least significant bits are a data size. 1 bit between the pointer and 
the data size is an invalidity flag, 

[0276] What is pointed to by a pointer is the start position of a unit of additional information. A pointer expressed by 
50 the 1 6 most significant bits has a value in the range 0x0000 to OxFFFF. A unit of additional information to be described 

later is described by using DataSlot-OOOO to DataSlot-FFFF. The pointer is an offset relative to DataSlot-OOOO located 

at a byte address of OxBOOO. That is to say, the pointer points to a slot position at an offset relative to data-slot 0000 at 

0x8000 or the offset is represented by the pointer. The data size is the total amount of data representing the additional 

information for the piece of music. 
55 [0277] To be more specific, the data size described in the 1 5 least significant bits is the total number of slots. A unit 

of additional information thus starts from the beginning of a slot and ends at a position in a last slot for the information. 

The area between the position and the end of the last slot is filled up with 00. 

[0278] The invalidity flag of an index pointer is identification information indicating whether the unit of additional 
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information pointed to by the index pointer is valid or invalid. An invalidity flag of 0 indicates a valid unit of additional 
infomnation and an invalidity flag of 1 indicates an invalid unit of additional information. 

[0279] It should be noted that the first index pointer normally denoted by INF-409 points to the unit of additional 
info'rm'atfon for the album as a whole. 
5 [0280] As explained above, a unit of additional information including the substance of actual additional information 
Is described in 1 data slot or a plurality of data slots 0000 to FFFF of the additional-information file with a slot used as 
a unit of description. 

[0281] Fig. 20 is a diagram showing the data structure of a unit of additional information. 

[0282] As shown in the figure, the unit of additional information Includes a header of 8 bytes at the beginning of the 
10 unit. 

* IN (1 byte) 

[0283] This data is a constant IN of 0x69. 

75 

* ID (1 byte) 

[0284] This information identifies the type of additional information. There are many types of additional information. 
This information is also referred to as a key ID to distinguish it from an SID (sub-ID) described below. 

20 

* SID (1 byte) 

[0285] A sub-ID which is T. B. D also represents a type. 
25 * SIZE (2 bytes) 

[0286] This information is the number of slots representing the size of the unit of additional information indicated by 
the ID. The size of the unit has a value in the range 1 to 7FFF. The most significant bit MSB of the size is an Invalidity 
flag. To be more specific, an MSB bit of 0 indicates a valid unit of additional information while an MSB bit of 1 indicates 
30 an invalid unit of additional information. 

* MCode (2 bytes) 

[0287] This information is the recorded code of the equipment maker 
35 [0288] Such a header is followed by data having a variable length. The data is the substance of actual additional 
information. 

[0289] Fig. 21 is a diagram showing typical additional information. 

[0290] A SIZE value of OxSxxx indicates that the data has been deleted or is invalid. The type of the additional infor- 
mation is indicated by the key ID and the SID described in the header. Details of these codes are not described since 
40 values of the key ID and the SID have not been defined yet. 

[0291] Additional information includes a copyright code called an ISRC (International Standard Recording Code), 
musical information such as the names of a song writer and an artist and hardware control information. In the case of 
musical information, 2 bytes are added to the beginning of the data for indicating the character code of the musical infor- 
mation. 

45 [0292] Fig. 22 is a diagram showing the data structure of a unit of additional information. Some examples of addi- 
tional infonnation are explained by referring to this data structure. 

[0293] Fig. 23 is a diagram showing the data structure of additional information which is a time stamp. As shown in 
Fig. 21 , the time stamp is a recording time stamp. 

[0294] Data of the time stamp is stored in the YMDhms format. If the whole slot is not occupied by the time stamp, 
50 the remaining area is filled up with 00. 

[0295] Fig. 24 is a diagram showing the data structure of additional information which is a playback log file. As 
shown in the figure, pieces of YMDhms data are logged where notation YMD stands for Year, Month and Day whereas 
notation hms is an abbreviation of hour, minute and second. 

[0296] Fig. 25 is a diagram showing the data structure of additional information which comprises the name of an 
55 artist, an ISRC code and a TOCID. In this example, the name of the artist is described in a slot in terms of 1-byte codes. 
The remaining area in the slot is filled up with 00, The next slot is an ISRC code stored as data. The last slot is data of 
a TOC-ID. Assume that the additional information shown in Fig. 25 is deleted. In this case, the additional information 
shown in Fig. 25 turns into one shown in Rg. 26. To be more specific, SIZE is updated to 8xx3i:x. 
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5. File Recording Processing 

[0297] The following description explains processing carried out by the drive apparatus 20 to record audio data and 
additional information into the memory sheet 1 having the configuration described above with reference to a flowchart 
5 shown in Fig. 27. 

[0298] As shown in Rg. 27, the flowchart begins with a step F1 01 at which the CPU 41 carries out processing to 
record an audio signal supplied to the drive apparatus 20 via the digital input temninal 27, the microphone input terminal 
25, the line input terminal 26 or the USB connector 28 into the memory sheet 1 as a data file in accordance with a 
recording operation carried out by the user. 

10 [0299] To put in detail, the CPU 41 drives each input system and components such as the DSP 49 to carry out nec- 
essary processing on the audio signal and stores the processed audio data into the RAM 41b. 
[0300] The CPU 41 further carries out processing to authenticate- the memory sheet 1 through the memory inter- 
face 42 by using the SAM 50. When the authentication processing is successfully finished, the audio data stored in the 
RAM 41b is encrypted and the result of the encryption is supplied to the memory sheet 1 to be recorded therein as 1 

15 data file or a plurality of data files (tracl<s). 
* [0301] When the processing to record 1 data file or a plurality of data files described above is completed, the flow 
of the processing goes on to a step F102 at which the traclc-information management file TRKLIST.MSF is updated. 
[0302] In order to update the track-information management file TRKLIST.MSF, the CPU 41 generates pieces of 
data to be stored in a track-information area TRKINF and a part-information area PRTINF on the RAM 41 b for each of 

20 the data files recorded in the memory sheet 1, reconfiguring data of the track-information management file TRK- 
LIST.MSF shown in Rg. 12. The reconfigured track-information management file TRKLIST.MSF is supplied to the mem- 
ory sheet 1 in order to update the track-information management file TRKLIST.MSF already existing in the memory 
sheet 1 . 

[0303] Then, the flow of the processing goes on to a step F1 03 at which processing Is carried out to input additional 

25 infonnation to be associated with the data files recorded In the memory sheet 1 this time. 

[0304] Examples of the additional Information are the names of a piece of music and an artist entered by the user 
in an edit operation or various kinds of information supplied to the drive apparatus 20 along with the audio signal. 
Assume that the audio signal is digital data supplied to the drive apparatus 20 through the digital input terminal 27 or 
the USB connector 28. In this case, various kinds of information may be transmitted along with the audio signal. Addi- 

30 tional information can then be generated on the basis of the transmitted information. 

[0305] When additional information is received from the user or an external apparatus as described above, the CPU 
41 generates a new additional-information file INFLIST.MSF or updates the existing additional-infonnation file 
INFLISTMSF including the additional information as a unit of additional information in the RAM 41b. It is needles to say 
that, at that time, an index pointer INF-nnn shown in Fig. 19 for the unit of additional information is also set 

35 [0306] After the additional-information file INFLIST.MSF is generated, the flow of the processing goes on to a step 
F1 04 at which the CPU 41 updates the track-information management file TRKLIST.MSF for the additional-information 
file INFLISTMSF In this case, in order to associate a unit of additional infonnation in the additional-information file 
INFLIST.MSF pointed to by an index pointer with 1 or a plurality of recorded data files, pointers INF-nnn shown in Rg. 
12B are set in the track-information areas TRKiNF corresponding to the recorded data files. 

40 [0307] The track-infomnation management file TRKLIST.MSF reconfigured in this way is then supplied to the mem- 
ory sheet 1 to update the track-information management file TRKLIST.MSF already existing in the memory sheet 1 . 
[0308] The flow of the processing then goes on to a step F1 05 at which the additional-information file INFLISTMSF 
generated at the step F1 03 is supplied to the memory sheet 1 to record the additional-information file INFLIST.MSF In 
to the memory sheet 1 or to update the additional-Information file INFLIST.MSF already existing in the memory sheet 1 . 

45 [0309] By recording data files of typically pieces of music, recording or updating an additional-information file 
INFLIST.MSF and recording or updating a track-information management file TRKLIST.MSF, 1 piece of music or a plu- 
rality of pieces of music can be each recorded as one of the data files and controlled properly. In addition, accompany- 
ing additional information can also be recorded. 

[0310] It Is also obvious from the above explanation that additional information or, strictly speaking, units of addi- 
50 tional information each associated with a data file are controlled as follows. A unit of additional information is pointed to 
by an index pointer INF-nnn in the additional-information file INFLIST.MSF. In addition, the index pointer INF-nnn is 
pointed to by a pointer INF-nnn in a track-information area TRKINF which is located in the track-information manage- 
ment file TRKLIST.MSF and associated with the data file. 

[0311] Since additional information is controlled by pointers organized in a 2-stage configuration as described 
55 above, later processing to edit the additional information can be made very efficient. 

[0312] For example, various kinds of edit processing can be carried out by merely updating the track- information 
management file TRKLIST.MSF having a small size without the need to update the additional-information file 
INFLISTMSF whk:h has a large size. In addition, special control can also be executed by updating the track-information 
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management file TRKLIST.MSR Examples of the special control are transferring additional information from a data file 
to another and associating a plurality of data files with a piece of additional information. 

[0313] It should be noted that additional information for the entire memory sheet is recorded independently of 
processing to record a data file. 
5 [0314] When the user enters additional information for the entire memory sheet, the pieces of processing of the 
steps F1 03 to F105 of the flowchart shown in Fig. 27 are can-ied out. In this case, a pointer updated at that time is used 
as the pointer INF-S in the track-information management file TRKLIST.MSF shown in Rg. 12A and, typically, the index 
pointer INF-409 among the index pointers shown in Fig. 19A is used as an index pointer in the additional-information 
file INFLIST.MSR 

10 [0315] As described above, additional information for a data file is recorded along with the data file. It should be 
noted that additional information for an existing data file can of course be recorded as well, in this case, for the existing 
data file to be associated with the additional information, the pieces of processing of the steps F1 03 to F1 05 of the flow- 
chart shown in Fig. 27 are carried out. 

75 6. RIe Deletion Processing 

[0316] The following description explains processing to delete a data file and additional information associated with 
the data file by referring to a flowchart shown in Rg. 28. 

[0317] As shown in Rg. 28, the processing begins with a step F201 at which the CPU 41 receives a deletion corn- 
ea mand when the user specifies a recorded data file and carries out an operation to delete the specified data file. At the 
next step F202, a pointer INF-nnn in a track-Information area for the data file to be deleted is read out from the track- 
information management file TRKLIST.MSF of the memory sheet 1 which was loaded previously in the RAM 41b. 
[0318] At the next step F203, the additional-information file INFLISTMSF is read out from the memory sheet 1 . At 
the next step F204, an index pointer INF-nnn in the additional-information file INFLISTMSF pointed to by the index 
25 pointer INF-nnn read out at the step F202 is updated to contents with the invalidity flag turned on, that is, with the inva- 
I'ldity flag set at '1 ' as shown in Fig. 1 9B. 

[0319] At the next step F205, the CPU 41 updates the track-information management file TRKLIST.MSF. To be 
more specific, the track-information area TRLINF-xxx and the part-information area PRTINF-xxx for the data file to be 
erased are deleted. In this way, the deletion of the data file is implemented. 

30 [0320] By deleting the track-information area TRLINF-xxx and the part-information area PRTINF-xxx , the areas 
allocated to the track-information area TRLINF-xxx and the part-information area PRTINF-xxx become a free area in 
the track-infomnation management file TRKLIST.MSF. Pieces of data stored in track-information areas TRLINF-xxx and 
part-information areas PRTINF-xxx for other data files following the free area need to be shifted forward. 
[0321 ] After the track-information management file TRKLIST.MSF is reconstructed as described above, at the next 

35 step F206, the reconstructed track-information nianagement file TRKLIST.MSF is supplied to the memory sheet 1 to 
update the track-information management file TRKLIST.MSF already existing in the memory sheet 1 . 
[0322] Subsequently, at the next step F207, the additional-information file INFLISTMSF updated at the step F204, 
that is, the additional-information file INFLISTMSF with the invalidity flag thereof turned on at the step F204, is supplied 
to the memory sheet 1 to update the additional-information file INFLISTMSF already existing in the memory sheet 1 . 

4o [0323] The processing to delete a data file is ended with the processing carried out at the step F207. 

[0324] In the processing described above, deletion of a data file itself is implemented by merely updating the track- 
information management file TRKLIST.MSF. In addition, since the track-information management file TRKLIST.MSF is 
a file with a relatively smail size, the deletion of a data file and reconstruction of data accompanying the deletion are not 
such a heavy processing load. 

45 [0325] Additional information associated with a deleted data file is erased by merely turning on the invalidity flag in 

the associated index pointer in the additional-information file INFLISTMSF. 

[0326] The size of the additional-information file INFLISTMSF increases with the amount of additional information 
stored therein. In the deletion processing, however, it is not necessary to reconstruct the whole additional-information 
file INFLISTMSF. Instead, only an associated index pointer needs to be updated. That is to say, the unit of additional 

50 information itself is not manipulated. Thus, the processing load does not increase. 

[0327] It is thus obvious from the above description that the processing to delete a data file and additional informa- 
tion associated with the data file can be carried out by a portable and compact drive apparatus 20 such as the one 
implemented by the embodiment, that is, an apparatus in which a high processing power can not be provided. In other 
words, the management system of additional Information in the memory sheet 1 allows an apparatus with a small 

55 processing power to carry out editing work without problems. 

[0328] It should be noted that there is conceived a case in which additional information for the entire memory sheet 
1 is deleted. In this case, the data-file deletion processing represented by the flowchart shown in Fig. 28 is carried out 
specially for the entire memory sheet 1 . To be more specific, at the step F202, it is from the pointer INF-S which is in 
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the header of the track-information managennent file TRKLIST.MSF that the index pointer is obtained. It is needless to 
say that the pieces of processing carried out at the steps F205 and F206 to update the track-information management 
file TRKLIST.MSF as part of deletion of a data file are not required in this case. 

[0329] " In addition, additional information associated with an individual data file can be deleted independently of the 
5 data file. That is to say, additional mformation associated with a data file can be deleted even though the data file itself 
is not. In this case, it is not necessary to carry out the pieces of processing at the steps F205 and F206 to update the 
track-information management file TRKLIST.MSF which are normally performed as part of deletion of a data file. 

7. Processing to Compress the Additional-Information File 

10 

[0330] After additional information is deleted by setting an invalidity flag as described above, the additional-informa- 
tion file can be reconstructed or compressed by using an apparatus having a high data processing power such as the 
personal computer 1 1 and a drive apparatus of a stationary type compatible with the memory sheet 1 . 
[0331] With the drive apparatus 20 having a not-so-high processing power as described above, the unit of addi- 
75 tlonal information itself, that is, the substance of additional information itself, ts not actually erased. As a result, a waste- 
fully used area Is left in the additional-Information file INFLST.MSF itself. 

[0332] Of course, such a wastefully used area can be left in the additional-information file INFLST.MSF as it Is. 
However, it is desirable to compress the additional-information file INFLST.MSF for the memory sheet 1 by removal of 
the wastefully used area from the additionai-informatlon file INFLST.MSF typically by means of the personal computer 
20 11. 

[0333] The following description explains processing to compress the additional-information file INFLST.MSF by 
utilizing the processing power of typically the personal computer 1 1 or a stationary drive apparatus by referring to a 
flowchart shown in Fig. 29. 

[0334] Fig. 29 shows a fiowchart representing the processing whicti is carried out by a CPU of a data processing 
25 apparatus with a high processing power such as the personal computer 1 1 or a stationary drive apparatus. 

[0335] For example, a stationary drive apparatus Is explained as a data processing apparatus having a high 
processing power. It should be noted that the configuration of such a data processing apparatus having a high process- 
ing power is the same as that of the drive apparatus 20 shown in Rg. 3 except that the data processing apparatus hav- 
ing a high processing power can be considered to be an apparatus with a CPU 41 having a high performance. For this 
30 reason, the configuration of such a data processing apparatus or the stationary drive apparatus for carrying out the 
processing represented by the flowchart shown in Fig. 29 is not explained. In the description of the processing, the cen- 
tral processing unit having a high performance is denoted by a CPU 41 H in order to distinguish it from the CPU 41 
shown in Fig. 3. By the same token, the other blocks are each denoted by a notation with the suffix H. 
[0336] As shown in Fig. 29, the flowchart representing the processing to compress the additlonal-infomr^ation file 
35 INFLiST.MSF begins with a step F301 when the user issues a request for such processing with the memory sheet 1 
mounted on the mounting/dismounting mechanism 22H employed in the data processing apparatus capable of carrying 
out the processing. It should be noted that the processing can also be carried out automatically at a point of time the 
memory sheet 1 is mounted. 

[0337] First of all. at the step F301, the CPU 41 H reads out the additional-information file INFLIST.MSF from the 
40 memory sheet 1 through the memory internee 42H and loads the file In the RAM 41 bH. 

[0338] Then, at the next step F302, a variable n Is set at 1 before going on to pieces of processing of a step F303 
and the subsequent steps. 

[0339] At the next step F303, the index pointer INF-(n) is read out from the additional-information file INFLIST.MSF. 
At the next step F304, the index pointer INF (n) Is examined to form a Judgment as to whether or not the Invalidity flag 

45 included therein is turned on or off. 

[0340] If the invalidity flag is found turned on, the flow of the processing goes on to a step F307 at which the variable 
n is examined to form a judgment whether the unit of additional infonnation pointed to by the last Index pointer INF-(n) 
has been processed. If the unit of additional information pointed to by the last index pointer INF-(n) has not been proc- 
essed, the flow of the processing goes on to a step F308 at which the variable n is Incremented by 1 . Then, the flow of 

50 the processing goes back to the step F303. 

[0341] If the outcome of the judgment formed at the step F304 indicates that the ln\^lidity flag is turned off, on the 
other hand, the flow of the processing goes on to a step F305 at which the subsequent index pointers IN F-(n) are shifted 
upward. Then, at the next step F306, the units of additional information pointed by the shifted index pointers INF-(n) are 
also shifted upward as well. Subsequently, the flow of the processing goes on to the step F307. If the outcome of the 

55 judgment formed at the step F307 indicates that the unit of additional information pointed to by the last Index pointer 
INF-(n) has not been processed, the flow of the processing goes on to the step F308 at which the variable n is incre- 
mented by 1 . Then, the flow of the processing goes back to the step F303. The pieces of processing are carried out at 
the steps F303 to F306 repeatedly and the variable n is Incrennented by 1 in each iteration till the most recent last unit 
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of additional information is shifted upward at the step F306. With the most recent valid last unit of additional information 
shifted upward at the step F306, the outcome of the judgment formed at the step F307 will sooner or later indicate that 
the unit of additional infonnation pointed to by the last index pointer INF-(n) has been processed. 
[0342] The compression processing results in a new compressed additional-information file INFLIST.MSF like one 
5 shown in Figs. 30A and 30B. 

[0343] Fig. 30A is a diagram showing a typical additional-information file INFLIST.MSF obtained at the step F301. 
As shown in the figure, index pointers INF-001 to INF-005 point to additional-information units INFdata-001 to INFdata- 
005 respectively. 

[0344] Assume that, as a result of the deletion processing represented by the flowchart shown in Fig. 28, the inva- 
10 lidity flags of the index pointers INF-002 and INF-004 are set to indicate that the additional-information units INFdata- 
002 and lNFdata-004 have been deleted. 

[0345] In the compression represented by the flowchart shown in Fig. 29, the invalidity flags of the index pointers 
INF-001 to INF-005 are examined sequentially one after another by incrementing the variable n in the loop comprising 
the steps F303 to F308. If a set invalidity flag is found, the subsequent index pointers INF-(n) and the units of additional 

15 information pointed by the subsequent index pointers INF-(n) are shifted upward to create a new additional-information 
file INFLIST.MSF shown in Rg. 30B. As shown in this figure, the valid index pointers INF-001 , INF-003 and INF-005 as 
well as the additional -information unit INFdata-001, the additional-information unit INFdata-003 and the additional-infor- 
mation unit lNFdata-005 pointed to by the valid index pointers INF-001 , INF-003 and IN F-005 respectively are left in the 
new additional-information file INFLIST.MSF. The valid index pointers INF-001 , INF-003 and INF-005 are left in the new 

20 additional-information file INFLIST.MSF shown In Rg. 30B as the index pointer INF-001 and new index pointers INF- 
002 and INF-003 respectively whereas the additional-information unit INFdata-001, the additional-information unit INF- 
data-003 and the additional-information unit INFdata-005 are left in the new additional-information file INFLIST.MSF as 
the additional-information unit INFdata-001, a new additional -information unit INFdata-002 and a new additional-infor- 
mation unit INFdata-003 respectively. 

25 [0346] As the outcome of the judgment formed at the step F307 indicates that the unit of additional information 
pointed to by the last index pointer INF-(n) has been processed, the processing represented by the flowchart shown in 
Fig. 29 to compress the additional-information file INFLIST.MSF is finished. In this case, the flow of the processing goes 
on to a step F309, departing from the loop comprising the steps F303 to F308. In the case of the example shown in 
Figs. 30A and 308, the flow of the processing goes on to the step F309 after the index pointer INF-005 pointing to the 

30 additional-information unit INFdata-005 has been processed. 

[0347] At the step F309, the CPU 41 H supplies the new additional-information file INFLIST.MSF created as 
described above to the memory sheet 1 to update the additional-information file INFLIST.MSF already existing in the 
memory sheet 1. 

[0348] When the additional-information file INFLIST.MSF is updated, the processing to compress the additional- 
35 information file INFLIST.MSF is completed. As is obvious from Figs. 30A and 308, the additional-information file 
INFLIST.MSF does not include any index pointer INF-(n) with the invalidity flag thereof turned on and an additional- 
information unit INFdata-(n) pointed to by the index pointer IN F-(n), containing condensed data of a smaller amount. 
[0349] By carrying out the compression processing described above, the additional-information file INFLIST.MSF 
can be reconstructed into an optimally condensed data structure. The compression processing described above sup- 
40 ports the function to delete additional information by merely setting an invalidity flag. That is to say, a wastefully used 
area in the addition a l-infonnation file INFLIST.MSF obtained as a result of the processing represented by the flowchart 
shown in Fig. 28 can be eliminated. 

[0350] It should be noted that, in the case of compression processing carried out by the personal computer 1 1 , the 
drive apparatus 20 transfers the additional-information file INFLIST.MSF to be compressed to the personal computer 
45 11 which carries out the processing represented by the flowchart shown in Fig. 29 on the additional-information file 
INFLIST.MSF. Then, an additional-information file INFLIST.MSF newly created by the personal computer 11 is trans- 
ferred back to the drive apparatus 20 to be stored In the memory sheet 1 . 

[0351] The present invention has been exemplified by an embodiment. It should be noted, however, that the scope 
of the present invention is not constrained by the embodiment. In particular, the detailed processing procedure of each 

50 operation described above can conceivably be changed to a variety of modified versions. 

[0352] In addition, the recording medium referred to as the first recording medium in the system provided by the 
present invention is not limited to the sheet memory shown in Fig. 1 . That is to say, the first recording medium can be 
a solid-state memory having a different external shape such as a memory chip, a memory card or a memory module. 
It is also needless to say that the memory device does not have to be the flash memory. A memory device of another 

55 type can also be employed. Furthermore, the present invention can also be applied to a system employing a disc- 
shaped recording medium such as a mini disc, a DVD (Digital Versatile Disc), a hard disc and a CD-R instead of a solid- 
state memory. 

[0353] In the embodiment described above, additional information of an audio-data file for recording information 
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such as a piece of music is explained. It should be noted that the audio-data file is no nnore than an example. That is to 
say, the additional infomnation is not limited to a track or audio data stored in a file. For example, the present invention 
can also be applied to other files such as a moving-picture file, a still-picture file and a audio-data file in the same way. 
[0354] As is obvious from the above explanation, the present invention has the following effects. 

5 [0355] First of all, in the recording medium provided by the present invention, the additional-information file is used 
for recording 1 additional-information unit or a plurality of additional-information units each describing actual additional 
information and first pointers each pointing to one of the additional-Information units, whereas the track-information 
management file is used for recording second pointers which each point to one of the first pointers and are associated 
with data files or the entire recording medium. That is to say, a plurality of first pointers stored in the additional-informa- 

10 tion file are used for controlling additional-information units each describing the substance of actual additional informa- 
tion by associating each of the units of additional information to one of the first pointers. On the other hand, the second 
pointers stored in the track-lnfomriation management file are used for controlling the first pointers. In this way, since 
pieces of additional information for data files and the entire recording medium are controlled by pointers organized in a 
2-stage configuration, various kinds of edit processing can be carried out by merely updating the track-information man- 

75 agement file with a small size without the need to update the additional-information file having a relatively large size. As 
a result, there is exhibited an effect that the processing to edit additional information can be made very efficient. 
[0356] In addition, each of the first pointers stored in the additional-information file includes validity information indi- 
cating whether a unit of additional information pointed to by the first pointer is valid or Invalid. With such validity infor- 
mation, an actual unit of additional information can be deleted by merely updating the validity information included in a 

2o first pointer pointing to the unit of additional information. That is to say, there is exhibited an effect of an ability to imple- 
ment deletion of additional information by very simple processing. 

[0357] The data processing apparatus provided by the present invention records input additional information as a 
unit of additional information in the additional-information file into a recording medium in which additional information is 
controlled by a configuration of the first and second pointers as described above. In addition, when a unit of additional 
25 infonnation ts recorded, first and second pointers are also recorded so that the recorded unit of additional information 
is controlled as additional information on a data file or the entire recording medium. As a result, a recording medium 
with the management system described above can be implemented, allowing processing to edit additional information 
to be made very efficient. 

[0358] The data processing apparatus provided by the present invention deletes a unit of additional information 
30 from the recording medium by updating validity information included in the first pointer which is stored In the additional 
information and points to the deleted unit of additional information to change the validity information to invalid status 
indicating that the unrt of additional information pointed to by the first pointer including the validity information has been 
deleted. Therefore, the deletion of additional information is not such a heavy processing load. 

[0359} The above feature means that the apparatus is provided with a sufficient function for editing additional infor- 
ms mation even if the apparatus is merely a portable and compact data processing apparatus for example. 

[0360] The data processing apparatus provided by the present invention is capable of updating the additional-infor- 
mation file recorded on a recording medium by generating a new additional-information file including no invalidated 
units of additional information in accordance with validity information included in each first pointer in the current addi- 
tional-information file. For example, while a data processing apparatus with a relatively high processing power such as 
40 a personal computer is actually capable of processing the entire additional-infonnation ftle with a large size, such a data 
processing apparatus is merely used for reconstructing the additional-Information file in accordance with validity infor- 
mation. As a result, there is exhibited an effect of an ability to update the additional-infonnation file into a file with a data 
structure including no wastefully used area. 

45 Claims 

1. A recording medium for recording one or plurality of main data and one or plurality of sub data related to said main 
data, said recording medium comprising: 

50 a main data recording region for recording said one or plurality of main data; 

a sub data recording region for recording at least one of sub data file comprising said one or plurality of sub 
data and sub management data tor controlling recording locations of said sub data; and 
a management data recording region for recording link information for controlling said main data recorded in 
said main data recording region and linking said main data to said sub data file containing said sub data related 

55 to said main data. 

2. A recording medium according to claim 1 wherein said sub data recording region includes information for each one 
or plurality of sub data indicating whether said one or plurality of sub data is valid or invalid. 
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3. A method of recording data into a recording medium for recording one or plurality of main data, management data 
for controlling said main data and one or plurality of sub data related to said main data, said method comprising the 
steps of: 

5 recording said main data into said recording medium; 

recording said management data based on recording of said main data; 

recording a sub data file comprising said one or plurality of sub data into said recording medium; and 
updating said management data so as to record link information for linking said main data to said sub data file 
as one of said management data. 

10 

4. A method of recording data into a recording medium according to claim 3 wherein said sub data file comprises one 
or plurality of sub data and sub management data for controlling recording locations of said sub data. 

5. A method of recording data into a recording medium according to claim 3 or 4, said method further including a step 
15 of encoding saki main data executed before said step of recording said main data into said recording medium. 

6. An editing method for carrying out editing work by deletion of an invalid one of sub data recorded on a recording 
medium used for recording one or plurality of main data, management data for controlling said main data and a sub 
data file comprising at least one of said sub data related to said main data and sub management data for controlling 

20 said sub data wherein said sub data file is connected and linked to said management data, said editing method 
comprising: 

a data reading step of reading out said management data from said recording medium; 
a file reading step of reading out said sub data file from said recording medium in accordance with link Infor- 
ms mation of said management data; 

a deletion step of deleting management data associated with sub data Invalidated by sub. management data In 
said sub data file and deleting said sub data determined to be invalid from said sub data file in case said sub 
data is determined to be invalid on the basis of said sub management data in said sub data file; and 
a file writing step of writing back said sub data file with unnecessary information deleted at said deletion step 
30 into said recording medium. 

7. An editing method according to claim 6 wherein: said sub management data includes at least validity information 
indicating whether sub data stored in said sub data file is valid or invalid; and at said deletion step, said validity infor- 
mation is examined to form a judgment as to whether or not there is sub data to be deleted. 

35 

8. An editing method according to claim 6 or 7 wherein, at said deletion step, unnecessary information is deleted by 
copying only management data associated with valid sub data and said valid sub data to a new sub data file. 

9. An editing method for carrying out editing work by deletion of sub data recorded on a recording medium used for 
40 recording one or plurality of main data, management data for controlling said main data and a sub data file com- 
prising at least one of said sub data related to said main data and sub management data for controlling said sub 
data wherein said sub data file is connected and linked to said management data, said editing method comprising: 

a data reading step of reading out said management data from said recording medium; 
45 a file reading step of reading out said sub data file from said recording medium in accordance with link infor- 

mation of said management data; 

a rewriting step of rewriting a specific one or plurality of sub management data associated with sub data spec- 
ified to be deleted in said sub data file read out at said file reading step; and 

a file writing step of writing back said sub data file with said specific one or plurality of sub management data 
50 for said unnecessary sub data rewritten at said rewriting step into said recording medium. 

10. An editing method according to claim 9 wherein: said sub management data includes at least validity information 
indicating whether sub data stored in said sub data file is valid or Invalid; and at said rewriting step, said specific 
one or plurality of sub management data is rewritten by setting said validity information at Invalid status. 

55 

11. A recording apparatus for recording one or plurality of main data, management data for controlling said main data 
and a sub data file comprising at least one of sub data related to said main data and sub management data for con- 
trolling said sub data into a recording medium, said recording apparatus comprising: 
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recording means for recording said main data, said management data or said sub data file into said recording 
medium; 

first updating means for updating said management data stored on said recording medium on the basis of 
recording of said main data into said recording medium; 
5 sub data file generation means for generating sub management data for controlling at least one of sub data and 

creating a sub data file comprising at least said one of sub data and said sub management data; and 
second updating means for updating said management data so as to record link information associating said 
sub data file with said main data as one of said management data. 

10 12. A recording apparatus according to claim 11, said apparatus further having encoding means for encoding said 
main data before recording of said main data into said recording medium. 

13. An editing apparatus for carrying out editing worl< by deletion of an invalid one of sub data recorded on a recording 
medium used for recording one or plurality of main data, management data for controlling said main data and a sub 

75 data file connprising at least one of said sub data related to said main data and sub management data for controlling 
said sub data wherein said sub data file is connected and linked to said management data, said editing apparatus 

comprising: 

reading means for reading out said data from said recording medium; 
20 writing means for writing said data into said recording medium; 

judgment means for forming a judgment as to whether or not there is an invalid one of sub data on the basis of 
said sub management data in said sub data file read out from said recording medium by said recording means; 
and 

control means tor controlling work to edit said sub data file in case a result of said judgment formed by said 
25 judgment means indicates that there is an invalid one of sub data by execution of the steps of: 

deleting management data associated with sub data invalidated by said sub management data in said sub 
data file; 

deleting said sub data determined to be invalid from said sub data file; and 
30 controlling said write means to write said edited sub data file into said recording medium. 

14. An editing apparatus according to claim 13 wherein: said sub management data includes at least validity informa- 
tion indicating whether sub data stored in said sub data is valid or invalid; and judgment means forms a judgment 
as to whether or not there is sub data to be deleted on the basis of said validity information. 

35 

15. An editing apparatus according to claim 14 wherein said control means deletes unnecessary data by copying only 
sub management data associated with valid sub data and said valid sub data to a newly created sub data tile. 

16. An editing apparatus for carrying out editing work by deletion of sub data recorded on a recording medium used for 
40 recording one or plurality of main data, management data for controlling said main data and a sub data file com- 
prising at least one of said sub data related to said main data and sub management data for controlling said sub 
data wherein said sub data tile is connected and linked to said management data, said editing apparatus compris- 
ing: 

45 access means for reading out and writing said data from and into said recording medium; and 

control means for controlling said access means to execute the steps of: 

rewriting a specific one or plurality of sub management data associated with sub data specified to be 
deleted In said sub data file read out by said access means; and 
50 writing back said sub data tile with said specitic one or plurality of sub management data rewritten into said 

recording medium. 

17. An editing apparatus according to claim 1 6 wherein: said sub management data includes at least validity informa- 
tion indicating whether sub data stored in said sub data tile is valid or Invalid; and said control means rewrites said 

55 specific one or plurality of sub management data by setting said validity information at invalid status. 
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EXAMPLE OF ADDITIONAL INFORMATION 

TYPE SIZE DESCRIPTION 

B BYTES TOC-ia Tbits/digit. (1+7X9) BINARY DISPUY 

FIRST MUSICAL NUMBER. LAST MUSICAL NUMBER AMD NUMBER OF THIS MUSIC 
TOTAL PERFORMANCE TIME (»sf) AND PERFORMANCE TIME OF THIS MUSIC (msf) 
ISRC CODE (58bits (6X5+ 4X7-» 32+32)) 

B BYTES ISRC (International Standard Recording Code} COPYRIBHT CODE 
12 DIGITS. 58 BITS (6X5+2. 4X7+6) 

12 DIGITS 11 TO 112 
11 TO 12 COUNTRY CODE 

13 TO 15 OWNER CODE 11 TO 15: 6 bit fomat X 5+2 bit Zero 
18 TO 17 RECORDING YEAR 

16 TO 112 SERIAL NUMBER 16 TO 112: 4 bit BCDX 7 +6 bit Zero 

7BYTB UPC/EAN/JAN CODE 52 bits (4X13- 8X7) 

VARIABLE BID REUTED INFORMATION 1 
YARIABlf BO KUm INFORMATION 2 

MUSICAL INFORMATION (CHARACTER CODE APPBIDEO TO 2 START BYTES OF DATA) 

VARIABLE LIBRETTO WRITER NAME 

VARIABLE SONG WRITER NAME 

VARIABLE DISC INFORMATION URL 

VAR I ABLE PATH TO L I BRETTO DATA 

VARIABLE PATH TO PICTURE DATA 

VARIABLE PATH TO MIDI DATA 

VARIABLE PATH TO E)ff>LANATORY DATA 

VARIABLE COMMBn* 

VARIABLE PATH TO CM DATA 

2 BYTES GBJRE CODE 

VARIABLE ALBUM NAME 

VARIABLE ARTIST NAME/GROUP NAME 

HARD CONTROL INFORMATION 



BYTE 
BYTES 



VARIABLE 

VARIABLE 

4 BYTES 

4 BYTES 

VARIABLE06) 

VARIABLE(16) 

VARIABLE 

VARIABLE 

VARIABLE 

4 BYTES 

4 BYTES 



AVERAGE VOLUME 

NUMBER OF PLAYBACK TIMES (NUMBER OF E)(ECUTIQNS/NUMBBt OF SPECIFICATIONS) 
FOR LfARNiNG PURPOSES 
TRANSMITTED MESSAGE 
RECEIVED MESSAGE 

PLAYBACK LOG DATA YEAR MONTH DAY HOUR MINUTE SECOND (YMDhms) 

PUYBACK RESUME POINTER (1-BYTE FUNCTION. 2-flYTt CLUSTER AMD 1-BYTE SU) 

GPS POSITION INFORMATION (PUYBACK) 

GPS POSITION INFORMATION (RECORDING) 

PASSWORD 1 

PASSmRO Z 

PATH TO CONTROL DATA 

RECOROINS TIME STAMP (VMDhns) WITH 2-SECOND RESOLUTION 

SUBTRACK (SEQUENCE NIUBER (2) AND SU (4)). THE SAME DESCRIPTION AS INX 
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